Content Security Policy (CSP) Generator

How to use this CSP generator

Work through the directives one at a time. For each, pick 'none' to block that resource type entirely, 'self' to allow only your own origin, or add specific origins in the text field — space- or comma-separated, so https://cdn.example.com https://fonts.googleapis.com is valid. The header at the bottom updates as you go, and any risky combination gets an inline warning right under the directive that caused it, so you see the trade-off the moment you make it rather than after shipping it.

Report-only first, then enforce

The single biggest mistake teams make with CSP is writing a policy from scratch and shipping it as an enforcing header on day one. Something always breaks — an analytics snippet, a font CDN, a widget you forgot about — and it breaks silently in production rather than showing up in a code review. The fix is built into the spec: Content-Security-Policy-Report-Only behaves exactly like Content-Security-Policy except that it never blocks anything. It only reports what would have been blocked, to whatever endpoint you set in report-uri or report-to.

Run report-only for long enough to see real traffic patterns — a few days for a high-traffic site, longer if traffic is light or usage is seasonal. Read the reports, add the legitimate origins you missed, and ignore the noise every CSP report endpoint gets from browser extensions and ad-blockers rewriting pages in ways your policy never anticipated. When the reports stop surfacing anything you need to fix, rename the header from Content-Security-Policy-Report-Only to Content-Security-Policy and you're enforcing the same policy you already validated.

Handling inline scripts: nonces and hashes

The temptation once something breaks is to add 'unsafe-inline' to script-src and move on — and that one checkbox undoes most of what the policy was for. CSP gives you two better options for legitimately allowing specific inline scripts. A nonce is a random, base64-encoded value your server generates fresh on every response and includes both in the header and as a nonce attribute on the script tags you trust:

Content-Security-Policy: script-src 'self' 'nonce-2726c7f26c';

<script nonce="2726c7f26c">
  // this runs — the nonce matches
</script>

A hash source works when the inline script's content never changes — you compute a SHA-256/384/512 hash of the exact script text (including whitespace) and list it in the policy. Any script whose content doesn't match a listed hash is blocked, nonce or not. Hashes suit a handful of static inline scripts; nonces suit server-rendered pages where the trusted script set is generated per request. Either approach lets you keep script-src free of 'unsafe-inline' while still allowing the inline code you actually wrote.

Why some checkboxes aren't offered everywhere

You'll notice 'unsafe-inline' and data: are only offered on default-src, script-src and style-src — they're the directives those keywords are actually meaningful for. base-uri and object-src only offer 'self' and custom origins, because in practice the only two sane values for either are "my own origin" and 'none' — anything else is an unusual, deliberate choice you should type in yourself.

Header vs. meta tag

The generator builds both, but they are not interchangeable. A <meta http-equiv="Content-Security-Policy"> tag cannot set frame-ancestors, report-uri, report-to or sandbox — the spec disallows them there and browsers drop them without warning, so the generator omits them from the meta output entirely rather than showing you a tag that silently does less than it looks like it does. Report-only mode has no meta equivalent at all; it only works as an HTTP header. If you control your server configuration, ship the header.

Once your policy is live, run it through the CSP checker to confirm it evaluates the way you expect, or check it alongside the rest of your response headers with the security headers checker.