CSP scanner

What does our CSP scanner check?

It reads the Content-Security-Policy header your server actually returns, not the one in your config file, and grades what it finds against the way browsers enforce it:

• Permissive keywords that switch the protection off, such as 'unsafe-inline', 'unsafe-eval' and 'unsafe-hashes'.
• Wildcards, scheme sources and shared hosts broad enough to let anything through, such as * or a bare https:.
• Known bypasses hiding in the origins you allow: JSONP endpoints and script gadgets that turn an allowlisted host into a way around your policy.
• Nonces and hashes that do not hold up: a nonce that never changes between responses, missing quotes, and values placed in a directive that ignores them.
• Missing directives that leave a side door open, such as object-src, base-uri and frame-ancestors, and whether default-src really covers the ones you left out.
• Deprecated and dead weight: directives the specification dropped, duplicate definitions, unknown values and separators browsers silently ignore.
• The enforced and the Report-Only policy, graded separately, because a Report-Only policy blocks nothing on its own.

How to check a website's Content-Security-Policy yourself

Open DevTools and go to the Network tab, then reload the page. Select the document request, the first one, whose name matches the page URL. Read its response headers and look for Content-Security-Policy. Check for Content-Security-Policy-Report-Only in the same list: a site can send one, the other, or both, and a Report-Only header on its own enforces nothing.

From a terminal, one line does the same job without opening a browser:

What our scanner adds on top is the judgement: a score out of 100, findings ranked by severity with the fix beside each one, and the enforced and Report-Only policies graded separately rather than run together.

curl -sI https://example.com | grep -i content-security-policy

Why a weak policy matters

One injected script is all it takes: stolen sessions, or a card skimmer sitting on your checkout for months. A Content-Security-Policy is the browser-side control that stops that script from running, and most of the web does not have one.

Across the 761,345 sites we scanned, only 19% serve a CSP at all, and where a policy does define script-src, that directive fails our security checks 89% of the time. Shipping any policy puts you ahead; shipping a strict one puts you in a small minority. The full numbers are in the State of the Web 2026 report.

How the scan works

Enter a URL, get a graded report a few seconds later: a shareable link, a re-scan button for checking the fix you just deployed, and CSV or PDF exports for the ticket or the audit trail. Free, no account, and it reads only your site's public response, the same thing every visitor's browser receives.

Scanner, evaluator, or full headers audit?

Use our scanner when the policy is live: it tests what your server actually sends, which is also what browsers and rating platforms see. For a draft, a staging policy or a colleague's proposal, paste it into the CSP evaluator and get the same graded analysis without a public URL. And when you want the whole posture in one pass, HSTS, X-Content-Type-Options, Permissions-Policy, cookies and the rest, run the security headers scanner instead: it scores the full header set and includes the CSP analysis as one part of it.