Paste a Content Security Policy header and read a graded audit. It flags unsafe-inline and unsafe-eval, wildcard and scheme only sources, a missing object-src and base-uri, an absent fallback, and the allowlisted domains that are known bypass gadgets because they host a JSONP endpoint or an old AngularJS build.
A Content Security Policy is a header that tells the browser which sources it may load script, style, frames, and other content from. Done well, it is the second line of defense against cross site scripting: even if an attacker injects markup, the browser refuses to run script the policy did not bless. Done poorly, it is a long string that looks protective while letting the same injection straight through. This tool parses each directive and audits the parts that decide which of those two you have, drawing on the model in the CSP Level 3 specification and the strict policy guidance from web.dev.
Most of the grade rides on script-src, because that is the directive that decides whether injected script runs. The tool fails a policy that keeps unsafe-inline with no nonce or hash to neutralize it, since that single keyword undoes the whole point of the policy. It flags unsafe-eval, which keeps string to code paths open. It fails a wildcard, a bare https: scheme, or a data: source in script-src, because each one lets an attacker host script almost anywhere. If neither script-src nor default-src is present, there is no script restriction at all, which the tool treats as a failure.
A strong policy stops listing hosts and instead trusts only the scripts your server marked for that one response. A per response nonce- value, or a sha256- hash of an inline script, tells the browser exactly what to run. Pairing that with strict-dynamic tells the browser to ignore the host allowlist and let an already trusted script load the ones it needs. The tool recognizes all three and rewards them, because a nonce based policy with strict-dynamic is far harder to bypass than a list of allowed domains.
This is the part that separates an audit from a plain linter. Some widely allowlisted domains are documented bypass gadgets: they serve a JSONP endpoint whose callback parameter reflects attacker chosen JavaScript, or they host an old AngularJS build whose template sandbox can be escaped into arbitrary execution. If one of these sits in your script-src, an attacker who can inject a script tag pointed at that allowed host runs code despite the policy. The tool carries a small curated list of such hosts and flags any that appear in your allowlist, because a single gadget can defeat an otherwise careful policy.
A few directives matter even when script-src looks clean. A missing or open object-src lets a legacy plugin element become a script execution path, so the strong default is object-src 'none'. A missing base-uri lets an injected base tag rewrite where every relative script URL resolves, which can quietly redirect a nonce protected script to an attacker host, so the strong default is base-uri 'none' or 'self'. A default-src is the fallback the browser uses for any directive you did not set, and frame-ancestors controls who may frame your page, which is the clickjacking boundary that the older X-Frame-Options header also covers.
Each graded check contributes a weighted share of a score out of one hundred. A pass earns its full weight, a weak setting earns part of it, and a dangerous one earns none. The grade is a fast signal about the policy as text, not a verdict on the whole site, because a policy is only as good as how completely it is deployed and whether report only mode is hiding violations you never see. Judging whether a policy actually holds means understanding what the page loads and how an attacker would probe it, which is the kind of context an AI security testing approach reasons about rather than pattern matching one header. For the wider set of injection boundaries attackers push on, see the access control writing.