CSP Inspector
Check and grade any page’s Content Security Policy — every directive, every source, and what a browser actually enforces.
What is a CSP checker?
A CSP checker reads the Content Security Policy a page sends and tells you what it really permits. A CSP is a list of directives — script-src, style-src, img-src and others — naming which sources the browser may load each kind of resource from. Done well it is the most effective defence against cross-site scripting; done carelessly it looks protective while permitting almost everything.
A policy is delivered per response, so this is a URL-level check: a marketing page, an admin console and an API on one domain routinely send different policies, so enter the exact URL you want to audit. HTTPSense’s CSP Inspector is free, needs no signup, and returns the parsed policy, an A–F grade, and a hardened version you can copy.
How to Use the CSP Inspector
- Enter a page URL and click Inspect CSP.
- Read the Summary tab for how the policy is delivered and how it scores on the six checks that matter most.
- Open Directives to see the effective policy — including which directives were inherited rather than declared.
- Work through Findings, which are ordered by severity and each carry a specific fix.
- Copy the suggested policy from Hardened, test it in report-only mode, then enforce it.
How the CSP Inspector Works
When you submit a URL we fetch it once, following redirects, and take the policy from three places: the Content-Security-Policy header, the Content-Security-Policy-Report-Only header, and any <meta http-equiv="Content-Security-Policy"> tag. A comma inside a CSP header separates independent policies, so a response carrying several is split back into each one.
Each policy is tokenised into directives and source expressions following the CSP Level 3 grammar. We then build the effective policy: for every resource type we walk the real fallback chain — script-src-elem to script-src to default-src — marking which directives were inherited rather than declared. When several policies are enforced, a browser requires all of them to allow a request, so we intersect them and label the result.
The resolved policy is checked against a catalogue of findings, each with a severity and a remediation, and scored into an A–F grade. We do not run a browser or execute JavaScript, so a policy injected client-side after load is not visible, and findings describe what the policy permits rather than what your page does. Results are stored, so a policy that loosens after a deploy is visible as a change.
Key Features
- Every delivery path — Enforced headers, report-only headers, and
<meta>policies, including directives browsers ignore in a meta tag. - Real fallback resolution — The effective policy per resource type, flagging directives that never inherit from
default-src. - Source classification — Every expression labelled nonce, hash, scheme, host, wildcard or unsafe keyword, colour-coded by risk.
- Ranked findings — Critical through info, each with a plain-English fix.
- Hardened policy — A deterministic, copy-ready tightening of your policy.
- Raw JSON — The complete response for scripting and CI checks.
Common Use Cases
- Security engineers — Audit a policy for
unsafe-inline,unsafe-evaland wildcards before signing off a release. - Frontend developers — Confirm a nonce-based policy resolves as expected after migrating off inline scripts.
- DevOps engineers — Catch a CDN or middleware rule that quietly added a second, conflicting policy.
- Compliance and audit teams — Produce a dated, graded record against an internal hardening standard.
Frequently Asked Questions
What does the CSP Inspector check?
It collects every Content Security Policy a URL delivers — from the Content-Security-Policy header, the Content-Security-Policy-Report-Only header, and any <meta http-equiv="Content-Security-Policy"> tag — then parses each directive, classifies every source expression, and resolves what a browser would actually enforce. You get the effective policy, findings ordered by severity, an A–F grade, and a hardened policy you can copy.
Is the CSP Inspector free?
Yes. Every HTTPSense tool is free to use and requires no signup, no API key, and no account. Enter a URL and you get the full result, including the raw JSON response for scripting.
How accurate are the results?
Parsing follows the CSP Level 3 grammar, and the effective-policy resolution implements the real fallback chains browsers use — including that base-uri, form-action and frame-ancestors never fall back to default-src at all. The findings are static analysis of the policy text: they tell you what the policy permits, not whether a page currently violates it.
What are the limitations of static CSP analysis?
We read the policy as delivered in the initial HTTP response, so a policy a single-page app injects later with JavaScript is not seen. We also do not run a browser, so a directive that is permissive but unused on your page is still flagged. Trusted Types directives are reported but not deeply validated.
How is this different from checking the header with curl?
curl shows you the raw header text; the difference is everything after that — resolving what each resource type falls back to, spotting an unsafe-inline that is silently ignored because a nonce is also present, intersecting multiple enforced policies, and ranking it all into findings with fixes. Each check is also persisted, so a policy that loosens after a deploy shows up as a change.
What is the difference between an enforced and a report-only policy?
A Content-Security-Policy header is enforced: the browser blocks whatever the policy disallows. A Content-Security-Policy-Report-Only header is evaluated identically but blocks nothing. Report-only is the right way to trial a policy, but a site running only report-only has no protection, so the Inspector grades it as a preview and caps the score.
Should I use a nonce or a hash for inline scripts?
Use a nonce when your server renders the page and can emit a fresh random value on every response, putting the same value in the header and in each script tag. Use a hash when the inline script is static. A nonce must be unpredictable and never reused — one baked into a cached page provides no protection.
Why is object-src flagged when I already set default-src?
Because "inherited from default-src" and "set to none" are different things. object-src does inherit from default-src, so default-src 'self' restricts plugin content — but the recommendation is object-src 'none' specifically, since almost no modern site needs <object> or <embed> and plugin content has a long history as a script-execution vector.