03Content-Security-PolicyEvaluator
CSP evaluator
Paste a policy and see what it really allows: every directive and fallback spelled out, and each weakness ranked with the change that fixes it.
Policy
header · meta tag · valuePaste a policy; it is checked as you type.
Summary
- High
- –
- Medium
- –
- Low
- –
- Notes
- –
- Directives
- –
- Scripts governed by
- –
Evaluation
What the evaluator looks for
The policy is parsed the way browsers parse it: directive names are case-insensitive, a repeated directive is ignored, and an empty fetch directive falls back to script-src or default-src as the spec says. Then each source list is checked.
- Script execution:
'unsafe-inline'without a nonce or hash,'unsafe-eval',*,https:,data:and hosts known to serve JSONP or user-published scripts. - Missing guards:
object-src,base-uri,frame-ancestorsandform-action, three of which never fall back todefault-src. - 'strict-dynamic': which parts of script-src modern browsers then ignore, and the policy that blocks every script because no nonce or hash is present.
- Mistakes: unquoted keywords such as
self, typos in directive names, deprecated directives and nonces that are too short or look like unfilled template placeholders.
To fix what you find, load the policy into the CSP generator with the button under the results.
CSP evaluator questions
Is 'unsafe-inline' always bad?
In script-src it allows injected inline scripts, which is what CSP exists to stop. Next to a nonce or hash it is ignored by modern browsers and only serves old ones, so it is reported as a note. In style-src it is a far smaller risk.
What if the response has two CSP headers?
Browsers enforce both: a resource must pass every policy. Paste them separated by a comma, as HTTP combines repeated headers, and each one is evaluated.
Why is a missing base-uri a problem?
An injected <base href> changes where relative script URLs point, and base-uri does not fall back to default-src. With nonce-based policies that can turn a trusted script tag into attacker code.