CSP Evaluator
Free CSP evaluator that checks a Content-Security-Policy header or meta tag in your browser: fallbacks, unsafe-inline, bypass hosts, nonces and hashes.
Updated
A header value, header lines (curl -sI output works), or meta tags.
Options
Set automatically for header lines and meta tags.
Hash an inline script
The text between the script tags, or the whole element. Whitespace counts.
Paste a Content-Security-Policy header value, header lines, or a meta tag.
What Is a CSP Evaluator?
The CSP evaluator reads a Content-Security-Policy header value, raw header lines, or a meta tag and rates how well the policy blocks script injection. It splits comma-separated policies, applies the CSP Level 3 parsing and fallback rules, and shows which directive governs each request type. Findings cover inline script, eval, wildcard and scheme sources, hosts on a known bypass list, missing object-src and base-uri, nonce and hash problems, and syntax errors.
How to Use the CSP Evaluator
- Copy the page's Content-Security-Policy response header, for example from the browser's developer tools or from the output of curl -sI https://your.site.
- Paste the header value, the header lines, or the page's meta tag. The tool detects which one it is.
- Read the verdict and the findings, which update as you type.
- Check the effective sources to see which directive and fallback apply to each request type.
- Copy the normalized policy, the strict starter policy, or a link that reopens the same check. The link keeps only the Content-Security-Policy lines, not the other headers you pasted.
How It Works
A Content Security Policy controls which resources a page can load or run. CSP Level 3 states that it aims to mitigate content injection attacks. A site sends the policy in a Content-Security-Policy header or in a meta element. One header value can hold several policies separated by commas, and a site can send several headers. A resource must pass every enforced policy, so each added policy can only restrict the page further.
Each request type uses the first directive present in its fallback list. Scripts use script-src-elem, then script-src, then default-src. Event handlers use script-src-attr, then script-src, then default-src. Workers use worker-src, child-src, script-src, and default-src, and frames use frame-src, child-src, and default-src. Only fetch directives fall back to default-src. frame-ancestors does not, so a policy with default-src 'none' still lets any site embed the page.
A nonce or hash in a script list makes browsers ignore 'unsafe-inline' in that list. With 'strict-dynamic', browsers also ignore host sources, scheme sources, and 'self' when loading script, and honor only the nonces and hashes. Browsers check eval() against script-src or its fallback, never against script-src-elem or script-src-attr. An empty directive, such as object-src with no value, allows nothing, and 'none' has no effect when other sources are listed.
CSP Level 3 calls a policy strict when script-src uses only nonce or hash sources with 'strict-dynamic' and base-uri is 'self' or 'none'. The web.dev strict CSP guide also sets object-src 'none' and adds https: and 'unsafe-inline' as fallbacks that browsers supporting 'strict-dynamic' ignore. CSP Level 3 adds that 'strict-dynamic' should be avoided when possible. web.dev states that host allowlist policies can be bypassed by attackers.
A policy in a meta element applies only inside head and not to content that comes before the element. Browsers do not support report-only mode, report-uri, frame-ancestors, or sandbox there. A Content-Security-Policy-Report-Only header makes the browser monitor the policy instead of enforcing it, and browsers ignore sandbox and upgrade-insecure-requests in it.
The evaluator checks script hosts against the list of JSONP and AngularJS hosts that ships with Google CSP Evaluator. Its README states that the list contains only popular bypasses and is not complete, and some JSONP bypasses on the list work only when the policy allows eval().
Fallback Lists
| Request type | Directives checked, in order |
|---|---|
| Script elements | script-src-elem > script-src > default-src |
| Event handlers | script-src-attr > script-src > default-src |
| Style elements | style-src-elem > style-src > default-src |
| Style attributes | style-src-attr > style-src > default-src |
| Workers | worker-src > child-src > script-src > default-src |
| Connections | connect-src > default-src |
| Manifests | manifest-src > default-src |
| Plugins | object-src > default-src |
| Frames | frame-src > child-src > default-src |
| Media | media-src > default-src |
| Fonts | font-src > default-src |
| Images | img-src > default-src |
| eval() | script-src > default-src |
Deprecated Directives
- block-all-mixed-content is obsolete. Browsers now block all mixed content that they cannot upgrade.
- prefetch-src is deprecated; avoid it in new projects.
- fenced-frame-src is deprecated and pending removal from browsers.
Standards
Scope
What It Checks
- +Reads header values, Content-Security-Policy header lines, curl -I output, and meta tags.
- +Splits comma-separated and repeated headers into separate policies and combines them the way browsers enforce them.
- +Shows the directive and fallback that apply to each request type, and which sources browsers ignore.
- +Flags inline script, eval, wildcard and scheme sources, hosts on Google CSP Evaluator's bypass list, missing object-src and base-uri, short nonces, wrong hash lengths, and syntax errors.
- +Computes SHA-256, SHA-384, and SHA-512 hash sources for an inline script.
What It Does Not Check
- -It does not fetch a site's headers.
- -It does not check that nonces change on every response.
- -It does not run the policy in a browser or list the resources it would block.
- -It does not rate style, image, font, or connection rules beyond their syntax.
- -Its list of bypass hosts is not complete.
Defensive Use
CSP Level 3 describes a policy as a way to mitigate content injection attacks by controlling which resources a page can load and run. web.dev states that under a strict policy based on nonces or hashes, attackers who find HTML injection flaws generally cannot use them to run malicious scripts. Checking a policy before deployment shows whether it gives that protection or relies on a host allowlist that attackers can bypass.
Frequently Asked Questions
What is a CSP Evaluator?→
The CSP evaluator reads a Content-Security-Policy header value, raw header lines, or a meta tag and rates how well the policy blocks script injection. It splits comma-separated policies, applies the CSP Level 3 parsing and fallback rules, and shows which directive governs each request type. Findings cover inline script, eval, wildcard and scheme sources, hosts on a known bypass list, missing object-src and base-uri, nonce and hash problems, and syntax errors.
What is the CSP Evaluator used for?→
Reviewing a Content Security Policy before deploying it, finding out why a browser blocks or allows a script, and confirming that a policy follows the strict pattern of nonces or hashes with 'strict-dynamic'.
Is my data sent anywhere?→
No. The CSP Evaluator runs in your browser. What you enter stays on this page and is not sent to ImmunitySec or anyone else.
How is the CSP Evaluator used defensively?→
CSP Level 3 describes a policy as a way to mitigate content injection attacks by controlling which resources a page can load and run. web.dev states that under a strict policy based on nonces or hashes, attackers who find HTML injection flaws generally cannot use them to run malicious scripts. Checking a policy before deployment shows whether it gives that protection or relies on a host allowlist that attackers can bypass.
What is a strict CSP?→
CSP Level 3 calls a policy strict when its script-src uses only nonce or hash sources with 'strict-dynamic' and its base-uri is 'self' or 'none'. The web.dev strict policy also sets object-src 'none'. web.dev states that under such a policy, attackers who find HTML injection flaws generally cannot use them to run malicious scripts.
Does default-src cover frame-ancestors?→
No. CSP Level 3 states that frame-ancestors does not fall back to default-src, so a policy with default-src 'none' still lets any site embed the page. Only fetch directives fall back to default-src; base-uri and form-action are document and navigation directives and have no fallback.
Why is 'unsafe-inline' ignored in my policy?→
When a script list contains a nonce or a hash, browsers ignore 'unsafe-inline' in it, and 'strict-dynamic' has the same effect. web.dev suggests keeping 'unsafe-inline' and https: next to a nonce only as fallbacks for very old browsers, because all recent browsers ignore 'unsafe-inline' when a nonce or hash is present.
Can I set a CSP in a meta element?→
Yes, inside the page's head. A meta policy does not apply to content before the element, and browsers do not support report-only mode, report-uri, frame-ancestors, or sandbox in it.
Can a site send more than one CSP header?→
Yes. Browsers enforce every policy they receive, so a resource must pass all of them and each added policy can only restrict the page further. A site can also send Content-Security-Policy and Content-Security-Policy-Report-Only together.
Is there a content security policy generator?→
This tool does not build a policy from a site's resources. web.dev publishes a nonce-based starter policy: script-src 'nonce-{random}' 'strict-dynamic' https: 'unsafe-inline'; object-src 'none'; base-uri 'none'. The server must replace {random} with a new value for every response, generated with a cryptographically secure random number generator and at least 128 bits long before encoding.
Bypass host lists from Google CSP Evaluator, licensed under the Apache License 2.0 and modified: the JSONP and AngularJS lists were copied into one file. Parsing and fallback rules follow the W3C Content Security Policy Level 3 Working Draft of 27 October 2026.