Content-Security-Policy-Report-Only on 30 homepages: one previews, 19 enforce

FIELD TEST · 2026-10-07 · 30 homepages · one HTTP request each · headers only

Sample and method: the fixed 34-domain panel in use since 2026-08-15, each homepage fetched once on 2026-10-07 with a browser user agent and no rendering. We read response headers only. Four sites answered 403 and were dropped; the 30 below answered 200.

A Content-Security-Policy-Report-Only header makes the browser evaluate a policy and report what it would have blocked, while still letting every resource load. It is the safe way to preview a policy before it takes effect. Across 30 homepages read once on 2026-10-07, 19 send a Content-Security-Policy and exactly one sends the Content-Security-Policy-Report-Only header first.

How we measured it

One HTTP GET per host, no retries, no JavaScript. The panel is a convenience set of developer-facing and news sites plus four of our own, not a random sample of the web, so read the counts as "among these 30", not "across the internet". We recorded a fixed list of security and caching response headers and, for any policy we found, the directive names present in its value.

The one homepage on the panel that ships a preview header is webflow.com. Every other site that sends a policy sends it straight into enforcement. Four sites — the four we operate ourselves — send no policy at all.

What the policies actually allow

The 19 enforcing policies are not tight. Fifteen of them include unsafe-inline, which lets a page run its own inline scripts regardless of the source list above it, and nine include unsafe-eval for the same reason on string-to-code calls. Those two keywords are the most common way a policy ends up far looser than it reads, and they are exactly the kind of thing a report-only pass would have surfaced before anyone enforced it.

Directive coverage is uneven: 15 of the 19 set style-src, 14 set script-src, 13 set a default-src fallback and 13 set frame-ancestors. Only seven set object-src, which the spec treats as a required companion to a script policy, and six set base-uri. Just three declare a report-uri where violations should be sent, and two pair a nonce- source with the rest of the policy.

Clickjacking protection is split across two headers. Counting both X-Frame-Options and frame-ancestors, 21 of the 30 homepages block framing in at least one way and nine do not block it at all. That includes all four of our own sites, which is the honest reason this paragraph is here.

Why a Content-Security-Policy-Report-Only header is the step people skip

A report-only header runs the same policy language, with one difference: the browser sends a violation report instead of refusing the resource. The policy is real, the enforcement is off. You get the list of what a strict policy would break — an inline event handler, a third-party font, an injected style block — while the page keeps working. The behavior is defined in the Content Security Policy Level 3 spec and described header by header on MDN (both checked 2026-10-07).

The usual sequence is the reverse. A team writes a policy, ships it enforcing, and finds out in production which of its own resources it just cut off. Fifteen of the 19 policies on this panel allow unsafe-inline, and that keyword is often added after a first enforcing rollout breaks something, not before it. The preview step exists to prevent exactly that, and almost nobody on the panel took it.

A policy you have never run in report-only mode is a policy you are enforcing for the first time in production.

What to do with this

The preview step is short, and it is the one thing this panel says almost nobody does. Run the policy you actually want as a report first, watch it for a week, then enforce the version that survived.

1. Send the strict policy you actually want under Content-Security-Policy-Report-Only first, and leave it there for a week of real traffic.
2. Point report-uri (or the newer report-to) at an endpoint you control and collect the violation reports. Without somewhere for them to go, report-only mode is silent and tells you nothing.
3. Read the reports for the resources you cannot give up, add those sources deliberately, and only then move the same policy to the enforcing header.
4. Re-fetch the header after the switch. A policy that quietly grew unsafe-inline during rollout is not the policy you reviewed.

If you do not run a policy at all, that is a separate decision — the four sites we operate fall into it, and this measurement is the reason we can state it plainly instead of assuming. Blocking framing is the cheaper half: frame-ancestors on a single line closes a clickjacking gap without touching how your own page loads. If you want the full picture of how a policy interacts with your own rendering, the handbook walks through content security policy one directive at a time; the unsafe-inline across 27 homepages measurement is the sibling to this one. And once the header is right, check the page itself with our AI crawler accessibility check.

Common questions

Does Content-Security-Policy-Report-Only block anything?

No. It reports and allows. That is its entire purpose, and the reason it is the safe first half of a rollout. The trade-off is that the page keeps whatever risk the policy was meant to reduce until you switch to the enforcing header.

Can I send both a report-only and an enforcing header?

Yes, and the spec lets a site run a looser enforcing policy next to a stricter preview. One homepage on this panel sends both. We did not compare the two policies line by line for that site, so we cannot say how far apart they were.

Why does almost nobody use report-only?

It adds a step and an endpoint, and it produces a report that has to be read by a person. The enforcing header can be copied from a template in a few minutes; the preview cannot. That gap shows up as a 19-to-1 split on this panel.

Is a Content-Security-Policy part of SEO?

Not directly, but it controls whether your own scripts, styles and fonts load at all. A policy that cuts off an inline script the page needs is a rendering problem, and a page that renders wrong is a page a search engine and an answer engine both read wrong.

One limit worth stating: we read headers from a single request each, so we cannot see a policy a site enforced in the past, and we did not follow any report-uri to check whether it is live. A site could run report-only on a different path, or behind a redirect we did not follow.