Declare what your site actually loads and this tool builds a strict, copyable Content-Security-Policy header. It favours nonces and strict-dynamic over origin allowlists, locks down the directives attackers reach for, and flags risky choices like unsafe-inline and wildcards as you make them.
Comma separated extra origins. Each directive defaults to 'self' if left blank.
A Content Security Policy is a response header that tells the browser which sources it may load and run on a page. Each directive covers a content type, like script-src for JavaScript or img-src for images, and lists the origins or keywords the browser should trust. The point is to contain cross site scripting: if an attacker manages to inject markup into your page, a strict policy refuses to execute script the policy never authorised, drawing on the source list rules in the CSP Level 3 specification. A policy is a defence in depth layer, not a replacement for escaping output. For how the underlying flaw works, see what XSS is and how it works.
The weak way to allow script is a list of origins: script-src 'self' https://cdn.acme.example. The trouble is that any script those hosts serve becomes trusted, and a popular CDN often hosts old or attacker friendly files that turn the allowlist into a bypass. The strong way is to authorise a specific script rather than a whole host. A nonce is a random value your server generates fresh for every response and puts both in the header, as 'nonce-r4nd0m', and on each trusted script tag as nonce="r4nd0m". An injected script tag has no matching nonce, so the browser refuses it. A hash, written like 'sha256-...', does the same for a known inline script by pinning its exact contents.
Real pages load script that loads more script, and listing every transitive origin by hand is fragile. The strict-dynamic keyword says: trust any script that a script I already trusted chose to load, and ignore the host allowlist entirely. So a single nonce on your entry point script propagates trust to its dependencies without you allowlisting their origins. This is what makes a nonce based policy practical for a modern app, and it is the shape of policy this generator emits when you pick nonce mode.
When a policy includes unsafe-inline in script-src, the browser will run any inline script and any inline event handler on the page, including ones an attacker injected. That is precisely the thing a Content Security Policy exists to stop, so a policy with unsafe-inline on scripts gives almost no cross site scripting protection no matter how careful the rest of it looks. Modern browsers ignore unsafe-inline when a nonce or hash is present, which is another reason to move to nonces. Inline styles via unsafe-inline in style-src are a milder concern, but they can still be abused, so this tool warns on both and pushes you toward nonce based scripts. The same readable, runnable surface drives DOM based XSS too.
A new policy almost always blocks something you forgot you load. Shipping it straight to enforcement breaks the page for real users. Report only mode solves this: the Content-Security-Policy-Report-Only header makes the browser check every request against your policy and report what would have been blocked, while letting it through. You watch the violation reports on a live site, add the legitimate sources you missed, and tighten until the reports are clean, then switch to the enforcing Content-Security-Policy header. Add a report-uri or report-to endpoint so those reports go somewhere you can read them.
A generated policy is a strong starting point, not a finished one, because a correct policy depends on exactly what your pages load. Always deploy it in report only mode first, collect violations, and adjust. When you have a candidate, paste it into the Security Headers and CSP Analyzer to grade it and surface weaknesses. Reasoning about whether a policy genuinely closes the gaps on a given app, rather than pattern matching one string, is the kind of judgement an AI security testing approach is built for. For the broader category of injection flaws a policy helps contain, see the injection and input writing.