Pages have no Content Security Policy

Why it matters

A Content Security Policy tells the browser which sources of script and other content a page may use. web.dev describes it as an added layer against cross-site scripting, recommends it for sites that handle sensitive user data, and notes that a policy can first be tried in report-only mode.

What to do

1. Look at the finding: it shows both responses we read and that neither carried an enforcing policy; a report-only header, if there is one, is listed but does not count.
2. Add a Content-Security-Policy response header, or a <meta http-equiv="Content-Security-Policy"> tag inside <head>, with a policy that fits the page's scripts.
3. If you want to test first, send the policy as Content-Security-Policy-Report-Only, then switch to the enforcing header: the report-only header alone does not clear this finding.

What we read

We read each crawled page's final response with our own user agent and its HTML without running JavaScript. When the first answer is a complete HTML page with 200, we request the same address a second time straight away, with the same request, and read both answers.

A page is reported when it is indexable, with no noindex and no canonical to another address, and neither answer has a Content-Security-Policy header or a CSP <meta> tag with content inside <head>. Any such header counts as a policy, even an empty one; a Content-Security-Policy-Report-Only header does not.

If the two answers disagree about whether an enforcing CSP is present, or the second request cannot be compared with the first, for example because the first answer set a cookie or more than 30 seconds passed, the page is marked as not checked instead of reported.

Example & evidence

Illustrative example — one page read twice, not a live audit.

https://bakery.example/order/ answered both requests with:

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Content-Security-Policy-Report-Only: default-src 'self'

Neither answer has a Content-Security-Policy header and the page's <head> has no CSP meta tag. The report-only header is shown but does not count, so the page is reported with both answers.

A possible correction, once the reports show nothing left to fix: send the same policy as Content-Security-Policy: default-src 'self'.

Confirm & check again

Check for yourself: open the page's response headers in your browser's developer tools and look for Content-Security-Policy; in the page source, search the <head> for Content-Security-Policy.

Check again: Full audit — run a new audit of the site. The finding closes when the page is crawled again, both answers are complete and agree that an enforcing CSP is present. If they disagree about that presence, for example while a policy reaches only some of your servers, the page is not checked and the finding stays open. It also closes if the page becomes noindex or names another page as canonical, which does not mean a policy was added.

Limits & sources

The check sees whether a policy is present, not whether it is strict or what the browser enforces. It reads HTML pages only and does not see a policy added by JavaScript. A <meta> policy in a page whose HTML leaves out the <head> tags is not counted, although browsers would apply it.

Confidence: High because two answers in a row are read directly and must agree.

Sources

• web.dev, Security headers quick reference — describes a Content Security Policy as an added layer against cross-site scripting, recommends it for sites that handle sensitive user data, and notes it can be set in report-only mode. Checked 28 September 2026.

Editorial review: 29 September 2026

Related

• Report-Only CSP lacks an enforcing response header — a report-only policy is sent without an enforcing header.
• A script policy declares unsafe-inline without a nonce, hash or strict-dynamic — a captured policy contains an effective unsafe-inline token for scripts.