Free CSP checker

Check whether your Content-Security-Policy is enforced, report-only, or missing, and see exactly how many directives it defines, in one scan, no signup.

We read one page, in one state, without signing in. Being clear about the edges is the point: a scanner that implies it sees everything is the one to distrust. See exactly what we can't see →

  • 2 checks each pass, fail, or needs review
  • Under a minute one page, one scan
  • No signup no account, no email

What we check

  • Content-Security-Policy (enforced)

    Content-Security-Policy: <policy>, for example script-src 'self'; object-src 'none'; base-uri 'self'

    Present and enforced, on any non-empty policy string; we never grade the directives inside it. The one exception: when the browser reports that your policy blocked requests the page itself made, a script or font your site chose to load, the check fails instead and names each blocked host and directive. The lookup is an exact key match, so a Content-Security-Policy-Report-Only header does not satisfy this check, on purpose, since it blocks nothing. A Content-Security-Policy sent with nothing after the colon fails as well, and we report that to you as missing.

    Without a CSP, nothing stops an injected <script> tag, whether from a stored XSS bug or a compromised third-party tag, from running with the full authority of your page: reading cookies, keylogging input, or redirecting your checkout to another origin.

    Learn more about Content-Security-Policy (enforced) →
  • Content-Security-Policy-Report-Only

    Content-Security-Policy-Report-Only: <policy>

    A separate, honest category, not folded into a fail: we count how many directives the report-only policy defines, for example a 13-directive policy, since a site running this has already done the hard part of deciding on a policy. We also read whether its reports are sent anywhere (report-uri or report-to) and whether script-src, or default-src without it, allows unsafe-inline or unsafe-eval. If reports are collected and neither is allowed, renaming the header is the step left; otherwise the finding says which of the two is missing and to settle that before enforcing.

    A report-only policy logs what it would have blocked to a report endpoint or the browser console, but it blocks nothing: an attacker's injected script runs exactly as if there were no policy at all, and the visible difference is a log entry no one may be watching.

    Learn more about Content-Security-Policy-Report-Only →

What we can't see

  • How strict your policy actually is: we report whether a Content-Security-Policy is enforced, report-only, or absent, not whether its directives, script-src, style-src, and the rest, would stop a real attack. The one directive read we make is on a report-only policy: whether its script rules allow inline or eval scripts.
  • A policy delivered only through a <meta http-equiv="Content-Security-Policy"> tag instead of a response header: we read response headers, so a meta-tag-only policy reads as missing here even though the browser still enforces it.
  • CSP violation reports your policy may already be collecting. We check whether the policy exists, not what it has caught.
  • Policies on pages other than the one scanned.

Ready to see where you stand?

Scan your site and get your Engineering Score with a prioritized roadmap in under a minute, no signup required.

Scan your site

Session expired

Your session has expired for security. Please log in again to continue.