CSP Evaluator
Check a Content Security Policy the way browsers read it: which directive governs each kind of resource, and what lets injected script run — unsafe-inline, wildcards, missing object-src and base-uri, bad syntax.
CSP Evaluator
Policy
Evaluate a Content-Security-Policy
Paste a policy to see which directives are set, which fall back, what is left open, and what would let injected script run.
The policy or the whole header line · several policies (comma-separated) are each evaluated
How is this calculated?
Directive names are case-insensitive and only the first of a repeated directive counts. Fallbacks follow the CSP3 "effective directive" rules. base-uri, form-action and frame-ancestors do not fall back to default-src, so leaving them out leaves those things open. When a nonce or hash is present, current browsers ignore 'unsafe-inline'; with 'strict-dynamic' they also ignore host and scheme sources and 'self', which is why a strict policy can safely list https: and 'unsafe-inline' as fallbacks for old browsers. A nonce needs at least 128 random bits — 22 base64 characters — and must be new on every response.Runs in your browser — nothing you enter leaves this device.
About this tool
What it does
Reads a Content Security Policy the way a browser does (CSP Level 3) and shows two things. First, for every kind of resource — scripts, inline event handlers, styles, images, fonts, fetch and WebSocket connections, frames, workers — which directive actually governs it after the fallbacks (script-src-elem falls back to script-src, then default-src; frame-src to child-src, then default-src; worker-src through child-src and script-src), and what it allows. Second, what weakens the policy: 'unsafe-inline' with no nonce or hash, 'unsafe-eval', wildcards and https: or data: in script-src, 'strict-dynamic' with nothing to start from, a missing object-src or base-uri, keywords written without quotes, malformed hashes, short nonces, repeated or misspelt directives, and directives that were removed from the standard.
How to use it
- Paste the policy — the value, or the whole Content-Security-Policy line. Several policies (comma-separated, or one per line) are each evaluated.
- Say whether it is delivered in the HTTP header or a <meta> tag (some directives are ignored in a meta tag), and whether it is Report-Only.
- Fix the findings marked Fix, then read the table to check each resource type is limited to what you expect.
Limits and your data
- It reads the policy, not your pages: it cannot tell whether your scripts actually carry the nonce, or whether an allowed host serves JSONP or user uploads.
- Host allowlists are flagged in general terms; the tool does not keep a list of known bypassable hosts.
- A nonce that never changes looks the same as a good one in a single response.
- The policy is read in your browser and never sent anywhere; the page works offline.
Questions
Why does my strict policy contain https: and 'unsafe-inline' and still get no errors?
Next to a nonce and 'strict-dynamic', current browsers ignore both. They are there for browsers too old to understand 'strict-dynamic', which would otherwise block every script.
What is wrong with script-src self?
Without quotes, self is read as a host name — a server called "self" — not as this site. Keywords must be quoted: 'self', 'none', 'unsafe-inline'.
Why does it ask for object-src 'none'?
<object> and <embed> can load content that runs script, and they are governed by default-src unless object-src says otherwise. Few sites need them, so 'none' closes the door.
Is report-uri wrong?
It still works but is deprecated in favour of report-to, which names an endpoint from a Reporting-Endpoints header. Keeping both covers every browser.