Content-Security-Policy Analyzer
Parse a Content-Security-Policy header into its directives and flag weak or missing protections.
Results are provided as is, for general information. Check anything important before relying on it. See the Terms of Use.
About this tool
A Content-Security-Policy header is a semicolon-separated list of directives, each restricting where one kind of content (scripts, styles, images, frames…) can load from. This tool parses a pasted policy into its directives and sources, then runs the checks that catch the mistakes that quietly gut a CSP's protection: 'unsafe-inline' or 'unsafe-eval' in script-src or style-src (including when inherited through default-src), a wildcard source on any directive, a missing default-src fallback, a missing or default-inherited object-src, and a missing frame-ancestors. It is not a full CSP linter — it does not validate every keyword against every directive — but it surfaces the handful of issues that account for most real-world weak policies. Parsing happens entirely in your browser.
When to use it
Questions
Why is 'unsafe-inline' considered dangerous specifically for script-src?
CSP's main job against XSS is stopping an attacker-injected <script> tag or onclick="…" handler from running. 'unsafe-inline' explicitly allows both, which means an injected inline script executes exactly as if there were no script-src restriction at all. The fix is a nonce or hash-based allowlist (script-src 'nonce-<random>' or 'sha256-<hash>') generated per response, so only scripts your server actually emitted can run.
Why does this tool flag 'unsafe-inline' even when it's only set on default-src?
default-src is the fallback for every fetch directive that isn't set individually — including script-src and style-src. If default-src carries 'unsafe-inline' and you haven't set script-src separately, inline scripts are just as unrestricted as if you'd written 'unsafe-inline' directly on script-src. This tool resolves that inheritance before checking, so it won't miss a weakness hiding behind the fallback.
What's actually wrong with allowing '*' on a directive like img-src?
A wildcard source means literally any origin — including one an attacker controls — can serve that content type. For img-src the risk is usually lower (tracking pixels, data exfiltration via image requests) than for script-src or connect-src, where '*' effectively disables the directive's protection entirely. This tool flags every wildcard at medium severity since the right fix — an explicit allowlist of the origins you actually use — is almost always available and meaningfully narrows the attack surface.
Why flag a missing object-src even when default-src is set?
object-src governs <object>, <embed> and <applet> — legacy plugin content that can execute in ways some browsers don't fully subject to the rest of CSP's script restrictions (a class of bypass documented against several older Flash-era CSP deployments). Because of that history, the standard hardening advice is to set object-src 'none' explicitly even when default-src already restricts it, rather than relying on the fallback. This tool marks that case as a low-severity note, and a full miss (no object-src, no default-src) as high.
What does frame-ancestors protect against, and why doesn't X-Frame-Options cover it?
frame-ancestors controls which sites are allowed to embed your page in an <iframe>, which is the primary defense against clickjacking. X-Frame-Options can do a similar job but only supports a single origin (via ALLOW-FROM, which most browsers dropped support for) or DENY/SAMEORIGIN — it can't express "allow these three specific partner origins." frame-ancestors is the modern, more expressive replacement; a CSP without it leaves clickjacking protection entirely up to whatever X-Frame-Options value (if any) is also set.
My policy has no warnings here — does that mean it's fully secure?
It means the policy passes this tool's specific checks, not that it's airtight. This tool doesn't validate every directive/keyword combination, doesn't check whether your allowlisted origins are themselves trustworthy (a CDN you don't control that also serves user uploads, for instance), and doesn't know your application's actual behavior. Treat a clean result as "no common red flags," not a certification.
Why does the tool ignore a directive I repeated twice in the same header?
This mirrors real browser behavior: when a directive name appears more than once in one Content-Security-Policy header, browsers honor only the first occurrence and silently ignore the rest. If you meant to add sources to an existing directive, add them to the first occurrence instead of repeating the directive name — CSP has no directive-level merging.
Can I use this to check a <meta http-equiv="Content-Security-Policy"> tag instead of a header?
Yes — paste just the content attribute's value (the part after content="…"), the same as you would a header value. The directive syntax is identical either way. One caveat worth knowing: a meta-tag CSP cannot set frame-ancestors, report-uri/report-to, or sandbox — browsers ignore those directives when delivered via meta tag, so a header-delivered policy is required if you need them.
What does an unrecognized directive name usually mean?
Almost always a typo (script-src misspelled as scirpt-src, for example) or a directive from a draft spec that never shipped. Browsers silently ignore any directive name they don't recognize — there's no console warning — so a typo'd directive provides zero protection while looking, at a glance, like it's doing something. This tool flags anything outside the current CSP Level 3 registry so a typo doesn't hide in a policy that otherwise looks complete.