Analysis runs in your browser. Fetch by URL asks our server to load that page.
CSP analyzer
Parse a Content-Security-Policy and grade it: unsafe directives, missing protections, deprecated syntax.
fetching asks our server to load the page and read its CSP header
paste the header value or the full Content-Security-Policy: line
Reading a Content-Security-Policy
Paste a policy — or fetch one from a URL — and each directive is parsed and graded the way browsers interpret it. Findings cover the classic holes: unsafe-inline, unsafe-eval, wildcards, data: in script sources, and the protective directives that are simply absent.
The analysis runs in your browser; only the fetch-by-URL mode asks our server to load a page and read its header.
I have a nonce and unsafe-inline. Is that broken?
No. When a nonce or hash is present, modern browsers ignore unsafe-inline entirely — it is left in place only for very old ones. The tool flags it as a legacy fallback rather than a hole, which is what it actually is.
Where do I start with a policy?
Send Content-Security-Policy-Report-Only with default-src 'self' and collect violations. Fix or nonce what shows up, wait until the reports go quiet, then move the same policy to the enforcing header. Writing a strict policy straight into enforcement is how sites break at 3am.
Why does it warn about a missing base-uri?
Because an injected <base> tag rewrites every relative URL on the page, including script sources, which turns a small HTML injection into script execution. base-uri 'none' costs nothing and closes it.
Do duplicate directives merge?
No — browsers honour the first occurrence and ignore the rest. A policy assembled by concatenating strings often ends up with two script-src directives, where the second, stricter one does nothing at all.
Related tools: Security headers, HTTP headers and SSL / TLS audit.