Content Security Policy Checker
Paste your existing Content-Security-Policy to check its quality, find security issues, and get improvement suggestions. Read the guide.
You can paste the raw value or include the Content-Security-Policy: header name.
Don't have a CSP? Build one with the generator.
CSP is primarily a defense against cross-site scripting (XSS), one of the most common web vulnerabilities. When a browser loads your page, it checks every resource request against the CSP. If a script, stylesheet, or other resource is not permitted by the policy, the browser blocks it and logs a violation. This means even if an attacker manages to inject malicious markup into your HTML, the browser will refuse to execute it as long as your CSP is properly configured. For framework specific guidance, see our CSP for React and Next.js guide.
The validator evaluates your policy across several dimensions: whether critical directives like default-src, script-src, and object-src are present, whether unsafe keywords like unsafe-inline or unsafe-eval are used, and whether the policy takes advantage of modern features like nonces and strict-dynamic. Each factor contributes to the final percentage score. If you are working with third party scripts, our third party CSP guide covers common patterns.
A Content Security Policy (CSP) is an HTTP response header that tells browsers which sources of content are allowed to load on your page. It acts as an allowlist: any script, stylesheet, image, or other resource not explicitly permitted by the policy will be blocked. This makes it one of the strongest defenses against cross-site scripting (XSS) and data injection attacks. See our full CSP guide for a deeper walkthrough.
The score reflects how well your policy covers the key directives and avoids common weaknesses. A higher score means your policy defines more directive types (like script-src, style-src, object-src), avoids unsafe keywords like unsafe-inline and unsafe-eval, and follows best practices such as using nonces or hashes for inline scripts. The score is a guideline, not a guarantee of security.
The unsafe-inline keyword allows any inline script or style to run on your page, which effectively disables CSP protection against XSS. An attacker who injects a script tag into your page can execute arbitrary code because the browser cannot distinguish between your inline scripts and the injected one. Replace unsafe-inline with nonce or hash based allowlisting for meaningful protection. Our removal guide walks through the process step by step.
Content-Security-Policy enforces the policy and blocks any content that violates it. Content-Security-Policy-Report-Only logs violations without blocking them, which is useful for testing a new policy before enforcing it. You can use report-only mode to collect violation reports, fix any issues, and then switch to the enforcing header once you are confident the policy works correctly. Learn more in our CSP reporting guide.
At minimum, include default-src to set a fallback for all resource types, script-src to control JavaScript sources, and object-src set to none to block plugins like Flash. Adding style-src, img-src, connect-src, font-src, and frame-ancestors rounds out a solid policy. The more specific your directives, the smaller the attack surface.
Yes. You can paste any CSP value directly into the validator to check it before adding it to your server configuration. This lets you catch missing directives, unsafe keywords, and syntax errors before the policy goes live. You can also paste the full header including the Content-Security-Policy: prefix and it will be stripped automatically.
CSP is just one piece of the puzzle. Run a full scan to see how your site scores across 15+ headers, TLS configuration, DNS records, and cookie security.
Scan your website