Defaults.Exposed › Reports

Content Security Policy Adoption in 2026: the 8.0% Web

Published 2026-08-18

Figures as of 16 August 2026 · methodology v9. This is a recurring report; each edition re-measures the same population so the numbers can be tracked over time. All figures are aggregate — we never publish an individual business’s grade or name an individual registrant’s domain.

Only 8.0% of the measured web has a working CSP

Of the 257,588,582 domains where the August 2026 census could read HTTP response headers, only 20,557,899 — 8.0% — serve a Content-Security-Policy that passes our quality bar. The other 92.0% either publish no policy at all or publish one that doesn’t do the job.

Content-Security-Policy is the browser’s instruction sheet for what a page is allowed to load and execute. Get it right and an attacker who manages to inject a script into your page finds the browser refusing to run it. Skip it, and injected code runs with your site’s full authority. The header has been around for well over a decade (CSP 1.0 reached W3C candidate recommendation in 2012 — industry context, not census data), it costs nothing to deploy, and browser support is universal. Adoption is still a rounding error.

And within that rounding error sits a second, quieter story. Among the domains that do publish a CSP, the score distribution is not the messy spread you’d expect from millions of independent decisions. It has two enormous towers, one arithmetic fingerprint of abandoned good intentions, and a vanishingly small summit. Most of the web’s CSP, it turns out, was never written by the site’s owner at all.

Key numbers

• 20,557,899 of 257,588,582 header-measurable domains (8.0%) pass the CSP check — an enforcing policy scoring at least 15 of 25 under methodology v9.
• 20,557,899 graded rows — 5.5% of all 376,928,781 in the census score histogram — show any CSP score above zero.
• 925,094 domains publish a visible CSP that still fails the quality bar — 4.5% of visible deployers, and that figure is a floor.
• A large majority of visible CSP deployers land on just two scores, 21 and 23 — the shape of platform defaults, not hand-written policies.
• 240,163 domains sit at exactly 10/25 — the arithmetic signature of a clean policy deployed in report-only mode and never switched on.
• 127,219 domains score a perfect 25/25 — about 0.034% of the graded web.

What does a Content-Security-Policy actually do?

A CSP is a single HTTP header that whitelists where scripts, styles, frames and other resources may come from. Its main job is blunting cross-site scripting: if script-src doesn’t allow inline scripts or attacker-controlled origins, injected JavaScript simply doesn’t execute. A good policy also locks down framing (frame-ancestors), plugins (object-src) and outbound connections (connect-src).

The catch is that a CSP is only as strong as its weakest directive. A policy that allows 'unsafe-inline' in script-src has re-opened the exact door CSP exists to close. A default-src * policy is a header-shaped shrug. This is why counting CSP headers tells you very little, and why this report scores them instead. Our earlier security header report card measured presence; this is the quality cut.

How many websites use CSP in 2026?

Two denominators, both stated plainly.

First, the applicable basis: 257,588,582 graded domains returned HTTP response headers we could evaluate. Of those, 20,557,899 pass the CSP check. That’s the 8.0%.

Second, the full score histogram, built on all 376,928,781 graded census rows. On that basis, 20,557,899 rows — 5.5% — show a CSP score above zero. The gap between 5.5% and 8.0% is the denominator: many graded domains have no readable web server at all, so the honest adoption question is “of sites we could measure”, and the honest answer is one domain in twelve.

For scale: over 332 million domains serve HTTPS in the same census round. CSP is not a fringe idea losing to obscurity. It’s a mainstream, free, universally supported control losing to inertia.

When is a CSP just theatre?

The brief for this piece asked a simple question: of the domains that bothered to publish a CSP, how many published one that doesn’t protect?

The measured answer: 925,094 domains — 4.5% of visible deployers — serve a CSP scoring below 15 of 25, the threshold our methodology sets for a policy that meaningfully restricts execution. These are sites that did the work of adding the header and still ended where they started, usually via 'unsafe-inline' in script-src, wildcard sources, or scheme-only allowances like a bare https: that permits scripts from anywhere on the encrypted web.

That 4.5% is a floor, for a blunt structural reason. In the histogram, a score of zero covers three indistinguishable cases: no HTTP response, no CSP header, and a CSP so permissive it earns nothing. A default-src * policy scores zero and disappears into the 266.3 million zero rows alongside every site that never tried. However many of those zero-scoring policies exist, they are theatre we cannot count — so every failure figure in this piece undercounts.

Then there’s the strangest bucket in the data. Exactly 240,163 rows sit at precisely 10/25 — the single largest score below the passing bar. Ten is a special number in our rubric: a policy served only as Content-Security-Policy-Report-Only gets 40% of its computed score, because report-only mode observes violations but blocks nothing. A flawless 25-point policy deployed report-only scores exactly 10. Some enforcing policies can also land on 10, so we frame this as an interpretation rather than a count — but the spike at precisely the report-only cap for a perfect policy is hard to read any other way. It looks like a quarter-million sites that wrote a good policy, turned on monitoring mode as every deployment guide advises, and never came back to flip the switch. Report-only forever is a dashboard, not a defence.

Why do so many CSPs cluster at exactly 21 and 23?

Here’s the full distribution of visible deployers, and it does not look like human variety.

Basis: 20,557,899 graded rows with CSP score ≥ 1, of 376,928,781 total. Score 24 is empty because the rubric’s deductions come in steps of at least two points — an artifact of the scoring, not the web.

Two scores, 21 and 23, hold 9,937,249 domains — 48.3% of everyone visibly deploying CSP. The platform-default reading remains compelling: when a handful of major hosting and site-builder platforms ship the same default policy to every tenant, every one of those tenants inherits the identical score — a solid policy docked the same two points for a missing frame-ancestors, or the same four for a permissive style directive. We can’t attribute the towers to named vendors from this dataset, so treat the platform-default reading as interpretation consistent with the shape — but the shape itself is a measured fact, and it’s the most load-bearing fact in this report.

It means much of the web’s CSP protection was never a decision anyone made at the site level. It arrived as a default. That’s genuinely good news for the tenants — secure-by-default platforms are how the mass-market web improves, a pattern we’ve measured before in the state of domain security. But it reframes the adoption number. Strip out the two towers and the population of sites that plausibly wrote their own policy is a small fraction of the visible total. Hand-rolled CSP, the thing security guides have spent a decade advocating, remains a niche craft.

Who actually scores 25/25?

127,219 domains. That’s 0.6% of visible CSP deployers and 0.034% of the graded web — roughly one domain in 3,000 among those that could be measured at all.

A perfect score under our rubric means an enforcing policy with no unsafe inline scripting (or inline re-enabled properly via nonces or hashes), no unsafe-eval, no wildcard or scheme-only script sources, sane style and connect directives, and an explicit frame-ancestors. Nothing on that list requires money. It requires knowing your own site’s resource graph, which is exactly the work most deployments — and most platform defaults — stop short of.

The summit being this small isn’t a scandal. It’s a measurement of how far “we have a CSP” sits from “our CSP would stop an injected script”. Between those two statements live tens of millions of domains.

How we measured this

• Population and round: August 2026 census, methodology v9, figures as of 16 August 2026. Scans run from our EU measurement infrastructure.
• Score histogram basis: all 376,928,781 graded evidence rows. Adoption-rate basis: 257,588,582 domains where HTTP response headers were retrievable, out of 376,928,781 graded domains.
• What the score is: the CSP check from our published v8 methodology, scored 0–25. The parser is directive-aware: it resolves default-src fallbacks, applies directive-specific deductions for 'unsafe-inline', 'unsafe-eval', wildcard and scheme-only sources, penalises a missing or wildcard frame-ancestors, and credits nonces and hashes that legitimately re-enable inline script. Report-only-only deployments receive 40% of their computed score. “Pass” = an enforcing policy scoring ≥ 15. Every quality claim in this report is a claim under this rubric, not a universal truth about CSP.
• The zero-score conflation: score 0 merges “no HTTP data”, “no CSP header” and “CSP earning zero points”. Present-but-worthless policies are therefore invisible, and all present-but-failing counts are floors.
• The report-only fingerprint: the 240,163 rows at exactly 10/25 are consistent with perfect policies capped by the report-only multiplier; enforcing policies can also score 10, so this is labelled interpretation, not a count.
• The platform-default reading of the 21/23 towers is likewise interpretation from distribution shape; the dataset does not attribute policies to vendors.
• Vantage limits: one header fetch per domain, from our vantage, at the root. Policies delivered via <meta> tags, varied per-path, or served differently to other geographies are outside this measurement.
• Industry context (CSP standardisation dates, browser support) is public knowledge, labelled as such, and not a census output.
• Aggregate only. We never name, grade or publish data about an individual registrant’s domain. Data is stored and processed within the EU.

What this means for developers, security teams, and business owners

If you run a website that allows any kind of user input — contact forms, login pages, comment fields, search boxes — CSP is the single most effective browser-side control against script injection attacks. The census data shows that 92% of measurable sites have no working policy, which means any successful injection attempt on those sites runs with full page authority: it can steal session cookies, redirect users to phishing pages, or silently log keystrokes. The absence of CSP does not cause injections; it means injections that do happen have nothing stopping them.

The 925,094 sites that have a CSP but failed the quality bar deserve specific attention. These sites have already done the configuration work — someone added the header, the infrastructure is in place — but the policy contains directives that undo the protection. The most common culprits are 'unsafe-inline' in script-src (which re-enables exactly the inline scripting CSP is meant to block) and wildcard source allowances (script-src *). If your site is in this category, the fix is not starting from scratch; it is auditing which existing directives undermine the policy and tightening them. That is an afternoon of work, not a project.

For organisations where a security team is separate from the development team: the 240,163 sites parked at report-only mode are the most actionable finding in this census. Someone wrote a policy, deployed it in monitoring mode, and left it there. The CSP violations being logged are security intelligence that has been accumulating without producing any protection. Enabling enforcement is a single configuration change — swapping the header name from Content-Security-Policy-Report-Only to Content-Security-Policy — and the work to justify that change is already done. If your organisation deployed CSP in report-only mode more than six months ago and never reviewed the violations, that backlog needs a meeting, not more logging.

Data to cite

• “Only 8.0% of the 257.6 million domains measured in the August 2026 census serve a Content-Security-Policy that passes quality review — meaning 92% of the measurable web has no effective script injection protection at the browser level.” — defaults.exposed August 2026 Domain Security Census (432M domains)
• “925,094 domains publish a Content-Security-Policy that fails the quality threshold — sites that did the work of adding the header but used directives like ‘unsafe-inline’ or wildcard sources that undo the protection.” — defaults.exposed August 2026 Domain Security Census (432M domains)
• “240,163 domains show the precise fingerprint of a CSP deployed in report-only mode and never enforced — a quarter million sites logging violations that produce zero runtime protection.” — defaults.exposed August 2026 Domain Security Census (432M domains)
• “Only 127,219 domains — 0.034% of the 376.9 million graded in the August 2026 census — score a perfect 25/25 on Content-Security-Policy, despite a perfect score costing nothing to achieve.” — defaults.exposed August 2026 Domain Security Census (432M domains)
• “48.3% of all visible CSP deployers cluster at exactly two scores — 21 and 23 — a pattern consistent with a handful of hosting platforms shipping one default policy to millions of tenants.” — defaults.exposed August 2026 Domain Security Census (432M domains)
• “CSP has been a W3C candidate recommendation since 2012 and has universal browser support, yet only 1 in 12 measurable domains serves an enforcing policy that meets quality standards in August 2026.” — defaults.exposed August 2026 Domain Security Census (432M domains)

FAQ

What percentage of websites use a Content-Security-Policy in 2026? Of 257.6 million domains where the August 2026 census could read response headers, 8.0% serve an enforcing CSP that passes our quality bar (≥ 15/25). Counting any visible CSP at all, including failing ones, the figure is 20.6 million — 5.5% of all 376.9 million graded census rows.

Does having a CSP header mean a site is protected against XSS? No. 925,094 measured domains publish a CSP that scores below our passing threshold, typically because 'unsafe-inline', wildcards or scheme-only sources re-permit exactly what CSP is meant to block. And that count is a floor: a policy weak enough to score zero is indistinguishable from no policy in our data.

Is a report-only CSP good enough? Report-only mode logs violations but blocks nothing, so on its own it provides zero runtime protection. It’s the right first step and the wrong permanent state. Our data shows 240,163 domains parked at exactly 10/25 — the precise score a flawless policy earns when served report-only — which reads like a large cohort that started the migration and never finished it.

Why do millions of sites have identical CSP scores? Because most visible CSP appears to arrive as a platform default rather than a hand-written policy. Two exact scores, 21 and 23, cover 48.3% of all visible deployers (9.94 million domains) — a convergence pattern consistent with a few large platforms shipping one policy to all their tenants.

How hard is it to score 25/25? Technically free, practically rare: 127,219 domains manage it, about 0.6% of visible deployers. It requires an enforcing policy with no unsafe inline script (or nonce/hash-based inline), no unsafe-eval, no wildcard script sources, and an explicit frame-ancestors. The cost is the audit of your own site’s resources, not money.

What should I do to improve my site’s CSP? Start with a CSP audit rather than writing a policy from scratch. Use browser developer tools or a CSP evaluation service to understand what resources your pages load, then build a policy that whitelists only those sources. If you already have a CSP in report-only mode, review the violation logs — they tell you exactly what the policy would block if enforced. Common quick wins are adding an explicit frame-ancestors 'self' (prevents your site being framed by other sites) and removing any 'unsafe-inline' directives where nonces or hashes can replace them.

How does CSP adoption in August 2026 compare to the prior census? The August 2026 census is the immediately following measurement after July 2026. The 8.0% passing rate reflects the state at 16 August 2026 across 376.9 million graded domains. CSP adoption has historically grown slowly and unevenly — primarily through platform defaults rather than individual operator action — which is consistent with the heavy clustering at scores 21 and 23 observed in this round.

Why does CSP matter for compliance and audit frameworks? PCI-DSS 4.0 introduced explicit requirements for CSP on payment pages, and multiple web application security frameworks (OWASP, CIS benchmarks) include CSP as a control. For organisations subject to those frameworks, the absence of an enforcing CSP on public-facing sites is a documented finding. The cost of implementing a baseline policy is lower than the cost of a finding during a QSA assessment.

See where your own domain stands

Check your domain free at defaults.exposed — see exactly how your domain scores on Content-Security-Policy quality, including whether your existing policy contains directives that undermine its protection. Takes 30 seconds. No account needed. Read the flagship State of Domain Security 2026 report.

Related: The HTTP Security Header Report Card · The Internet Security Grade Curve

How to cite this report

Press / blog: defaults.exposed (2026). Content Security Policy Adoption in 2026: the 8.0% Web. defaults.exposed August 2026 Domain Security Census (432,127,908 domains scanned, asOf 2026-08-16). Retrieved from https://defaults.exposed/en/articles/content-security-policy-adoption-2026

Academic: defaults.exposed. (2026, August 18). Content Security Policy Adoption in 2026: the 8.0% Web. In defaults.exposed Domain Security Census: August 2026. https://defaults.exposed/en/articles/content-security-policy-adoption-2026

In-line citation: (defaults.exposed, August 2026 Domain Security Census, n=257,588,582 header-measurable domains)

About the defaults.exposed August 2026 Census

The defaults.exposed Domain Security Census is a recurring independent measurement of the public domain namespace. The August 2026 edition scanned 432,127,908 domains between 1–16 August 2026 and graded 376,928,781 of them using methodology v9. Scans are conducted from EU infrastructure. No individual domain, registrant, or business is named in any report. All figures are aggregate distributions. Data is stored and processed within the EU.

Methodology: defaults.exposed/en/articles/domain-security-scoring-methodology-v9 Full census report: defaults.exposed/en/articles/the-state-of-domain-security-2026

Aggregate data only. Data stored and processed in the EU.