CSP Generator

Build a Content-Security-Policy that is worth deploying — starting in report-only.

What you provide

Result

PASS

Report-only policy generated

The nonce placeholder has to be replaced with a fresh random value on every response and repeated on each script tag — a static nonce is no better than allowing inline script, since an attacker can read it from the page. Report-only is the right way to start: the policy is evaluated and violations reported without anything being blocked, so you find out what the site actually loads before breaking it. Run it for a fortnight, read the reports, then switch the header name.

Response header
Content-Security-Policy-Report-Only: default-src 'self'; script-src 'self' 'nonce-{RANDOM}' 'strict-dynamic'; style-src 'self'; img-src 'self' data:; object-src 'none'; base-uri 'self'; frame-ancestors 'none'; form-action 'self'; upgrade-insecure-requests
Diagnostic telemetry
Directives
9
Script policy
nonce + strict-dynamic
Mode
report-only
Clickjacking
frame-ancestors 'none'

What this cannot tell you

  • Calculated in your browser. Nothing you enter is uploaded or logged.
  • A policy is only as good as what it allows. Choosing unsafe-inline for scripts removes most of the protection, and the generator says so rather than quietly emitting it.
  • The nonce placeholder must be replaced with a fresh random value on every response, generated server-side. A static nonce is no better than allowing inline script.
  • Cannot see what your site actually loads. Report-only mode is how you find that out, and it is the default here for that reason.
  • A policy is one layer. It reduces the impact of injected content and does nothing about the injection itself — output encoding and input validation are still the fix.

Take this with you

CSP Generator on RunTheTests — free browser-based websec tools, no sign-up.