How to use the csp evaluator
- Copy your
Content-Security-Policyheader value from your server configuration or browser developer tools. - Paste it into the text area above.
- Review the findings grouped by severity: high, medium and low.
- Update your policy to remove unsafe sources and add any missing directives.
How the csp evaluator checks your policy
The csp evaluator splits the header on semicolons to isolate each directive, then splits each directive on whitespace to extract the name and its source list. It compares every source against known dangerous values such as 'unsafe-inline', 'unsafe-eval', * and data:. It also checks that critical directives are present. object-src may be covered by a default-src fallback, but base-uri and frame-ancestors never fall back to default-src, so they are reported whenever they are missing.
For example, given script-src 'self' 'unsafe-inline' *, the parser identifies three sources. It flags 'unsafe-inline' as high severity because it allows inline event handlers and script blocks, and it flags * as high severity because it permits scripts from any origin.
The checks follow CSP Level 3 where it matters: a repeated directive is ignored after its first occurrence, and 'unsafe-inline' is downgraded to a low finding when the same directive also has a nonce, a hash or 'strict-dynamic', because modern browsers then ignore it. This is a static reading of the text. It does not know whether a host you allow serves JSONP or user-uploaded scripts, and it does not run the policy in a browser, so treat a clean result as a good start rather than proof of safety.
Severity levels explained
Findings are grouped into three severity levels to help you prioritize fixes.
| Severity | Meaning | Example |
|---|---|---|
| High | Directly enables cross-site scripting or code injection. | 'unsafe-inline' in script-src |
| Medium | Weakens the policy or allows unexpected content types. | blob: in script-src, or no base-uri |
| Low | Defense-in-depth gaps that block specific attacks. | No frame-ancestors directive |
A policy with zero high-severity findings is significantly harder to bypass than one that relies on 'unsafe-inline' for convenience.
Common Content Security Policy mistakes
Many policies start strict but accumulate exceptions over time. A frequent mistake is adding 'unsafe-inline' to script-src because a third-party library uses inline event handlers. The safer approach is to refactor the code or use nonces and hashes.
Another common issue is setting default-src * during development and forgetting to tighten it before deployment. The wildcard source defeats the purpose of the header entirely. Similarly, allowing data: URIs in script-src lets an attacker execute arbitrary code via base64-encoded scripts embedded in data URLs.
Without object-src, plugin content falls back to default-src, and with no default-src at all it is unrestricted. Setting object-src 'none' is the usual recommendation unless you specifically need plugins.
Essential directives for a strong policy
A well-constructed Content Security Policy includes several key directives beyond default-src.
- script-src: Controls where JavaScript can load from. Use nonces or hashes instead of
'unsafe-inline'. - object-src: Restricts plugins. Set to
'none'on modern sites. - base-uri: Prevents attackers from injecting a
<base>tag to redirect relative URLs. Set to'self'. - frame-ancestors: Supersedes the older
X-Frame-Optionsheader and is not covered bydefault-src. Set to'none'or specific trusted origins to prevent clickjacking. - upgrade-insecure-requests: Automatically upgrades HTTP subresource requests to HTTPS.
You can generate a starting policy using the CSP generator and then validate it here.
Testing your policy without breaking your site
Before enforcing a new policy, deploy it using the Content-Security-Policy-Report-Only header. This instructs browsers to evaluate the policy and send violation reports to a specified endpoint without actually blocking any resources. Monitor the reports for a few days to catch legitimate resources that would be blocked.
Once you have resolved all false positives, switch the header to Content-Security-Policy to enforce the rules. Keep this csp evaluator handy to re-check the policy whenever you add new third-party integrations or change hosting providers.
Worked examples
| Example | Input | Result |
|---|---|---|
| Strict policy | Content Security Policy header: default-src 'self'; script-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'none' | default-src: 'self'; script-src: 'self'; object-src: 'none'; base-uri: 'self'; frame-ancestors: 'none' |
| Weak policy with unsafe-inline | Content Security Policy header: default-src *; script-src 'unsafe-inline' 'unsafe-eval'; style-src 'unsafe-inline'; img-src data: | default-src: *; script-src: 'unsafe-inline' 'unsafe-eval'; style-src: 'unsafe-inline'; img-src: data: |
| Missing key directives | Content Security Policy header: default-src 'self'; script-src 'self' https://cdn.example.com | default-src: 'self'; script-src: 'self' https://cdn.example.com |
FAQ
What is a csp evaluator?
A csp evaluator is a tool that parses a Content Security Policy header and identifies weak or missing directives that could allow cross-site scripting or other injection attacks.
Why is unsafe-inline considered dangerous?
The 'unsafe-inline' source allows inline script tags and event handler attributes like onclick. If an attacker can inject HTML into your page, they can execute arbitrary JavaScript, defeating the purpose of the policy.
Does this tool upload my policy to a server?
No. The evaluation happens entirely in your browser using JavaScript. Your policy string is never transmitted anywhere.
What should I use instead of wildcard sources?
List only the specific origins your site needs, such as https://cdn.example.com. Avoid the * wildcard in default-src, script-src and other fetch directives.
Is frame-ancestors the same as X-Frame-Options?
The frame-ancestors directive in CSP controls the same thing as the X-Frame-Options header, which pages may embed yours, but it is more flexible because it accepts several origins. Modern browsers prefer frame-ancestors when both are present. It cannot be set through a meta tag.
Can I use nonces instead of unsafe-inline?
Yes. Generate an unpredictable nonce for every response, add it to your script tags as a nonce attribute, and include 'nonce-value' in script-src. This allows your own inline scripts without opening the door to injected ones. A nonce that is reused between responses gives no protection.
Why did a policy with a nonce still show 'unsafe-inline'?
When script-src has a nonce, a hash or 'strict-dynamic', browsers that support CSP Level 2 or 3 ignore 'unsafe-inline'. The evaluator lists it as a low finding because it only remains as a fallback for very old browsers.