Check a site for a Content-Security-Policy
A Content-Security-Policy (CSP) is a response header that lists which sources a page may load scripts, styles, and other content from. A good one is the strongest single defense against cross-site scripting, because injected code from a source the policy does not list will not run.
What it costs
On CheckWeb this is a weight-1 check on the Security axis, weighted lightly on purpose. A correct CSP is hard to author and is absent on a large share of even well-run sites, so CheckWeb treats a missing policy as a real gap worth closing rather than an alarm that tanks the score. It shows as a warning, not a hard fail.
How it looks in the report
Under the Security axis, this shows as "Content-Security-Policy" with a WARN status and "No Content-Security-Policy header" when absent. A site that sends a policy shows PASS.
Content-Security-Policy
No Content-Security-Policy header
Missing vs set
Missing
An injected `<script>` from any origin runs with the page's full privileges.
Set
A policy that restricts script sources to a known list. A policy that keeps `unsafe-inline` for scripts undercuts most of the benefit, so the goal is a policy without it.
How to fix it
- Start in report-only mode: `Content-Security-Policy-Report-Only` surfaces what a policy would block without breaking the page, so violations can be fixed first.
- Tighten until the report is clean, then switch the header to `Content-Security-Policy` to enforce it.
- Set it at any layer that sends response headers (Nginx, Apache, app middleware, or the edge).
- Then verify: re-scan.
Check a site for a CSP
Paste a URL to see whether a site sets a Content-Security-Policy. Fix, re-scan, and confirm.
Check my websiteFAQ
- Does Content-Security-Policy-Report-Only pass the check?
- No, and that is deliberate. Report-Only sends violation reports without blocking anything, so it protects nobody yet. It is the right way to author a policy, and the check turns green once the same policy moves to the enforcing Content-Security-Policy header.
- Where should a first policy start?
- With Report-Only on the real site rather than a hand-written guess. Collect violations for a week, fold the legitimate sources into the policy, then switch the header name to enforce it. Authoring a strict policy offline usually breaks something on the first deploy.
- Does a policy with unsafe-inline still count?
- It passes the check, because the check reads whether a policy is present, and a weak policy is a large step up from none. It is not the end state: unsafe-inline is what most cross-site scripting relies on, so moving inline scripts into files, or allowing them by nonce, is what turns the policy into a real defense.
- Will a CSP break analytics or embedded widgets?
- Only if their hosts are missing from the policy, which is exactly what the Report-Only phase surfaces. Every third-party script, font, style, and frame needs its origin listed in the matching directive, and anything left out stops loading once the policy enforces.