Guide

Content-Security-Policy Example

A good CSP should match what your page really loads. Start small, test carefully, and make it stricter as you remove risky patterns.

01

Strict Starting Point

A strict baseline is: default-src 'self'; base-uri 'self'; frame-ancestors 'none'; object-src 'none'.

Treat that as a starting idea, not a paste-and-forget answer. Most sites need explicit rules for images, fonts, analytics, APIs, payments, or embedded tools.

For an existing site, use Content-Security-Policy-Report-Only first. That lets you see violations without breaking real visitors.

02

Marketing Site Example

A marketing site often needs self-hosted scripts, trusted image domains, font sources, analytics, and no framing.

Keep third-party sources specific. Avoid allowing every subdomain from a provider unless the page truly needs it.

A simple direction is: default-src 'self'; script-src 'self' trusted-analytics.example; img-src 'self' data: trusted-cdn.example; style-src 'self' 'unsafe-inline'; frame-ancestors 'none'; object-src 'none'. Replace the example domains with the services your site actually uses.

03

App Dashboard Example

An app dashboard should usually block framing, avoid object-src, limit API connections, and use nonces or hashes instead of unsafe-inline.

Roll out CSP in report-only mode first so you can see what would break before enforcement.

A dashboard direction is: default-src 'self'; script-src 'self' 'nonce-randomValue'; connect-src 'self' api.example.com; img-src 'self' data:; frame-ancestors 'none'; base-uri 'self'; object-src 'none'. Generate a fresh nonce for each response instead of reusing the example value.

04

Directives To Understand

default-src is the fallback. script-src controls JavaScript. style-src controls stylesheets and inline styles. img-src controls images. connect-src controls fetch, XHR, WebSocket, and similar connections.

frame-ancestors controls who can embed the page. base-uri limits base tag abuse. object-src should usually be none because plugins and object embeds are rarely needed on modern sites.

05

Rollout Checklist

List what the page loads, write a narrow policy, test in report-only mode, fix violations, then enforce. Recheck with /security-headers-checker after deployment.

When a policy breaks a page, loosen only the directive that needs it. Avoid broad wildcards unless you have a clear reason.

Next
Fix a CSP error

Troubleshoot blocked scripts, styles, images, and APIs.

Check your CSP

Confirm whether the policy is live on the final response.

CSP reference

Review the main directives and what they control.

FAQ

Common questions

Should I use unsafe-inline?

Avoid it when possible. Nonces, hashes, and moving inline code into bundled files are safer long-term options.

What is report-only mode?

Report-only mode lets browsers report policy violations without blocking resources. It is useful before enforcing CSP on a site that already exists.

Can CSP replace secure code?

No. CSP can reduce damage from some browser-side bugs, but you still need secure application code and healthy dependencies.

What is a nonce?

A nonce is a random value generated for one response. Scripts with the matching nonce can run; injected scripts without it are blocked.

Can I use wildcards in CSP?

You can, but use them sparingly. Wildcards are easier to maintain, but they give more sources permission than a narrow allowlist.