Research

Published August 17, 2026 · 521,442 domains scanned

State of the Web 2026

Key findings

• Almost nothing resists script injection. 83 domains out of 521,442 pass, and 99.3% are exposed.
• A quarter of the web ships a Content-Security-Policy; 4.4% of those policies pass. A passing CSP exists on 0.97% of all domains.
• Nonces have not landed. 5.4% of policies use one, against 37.1% that still allow unsafe-inline.
• Reporting is a CDN artifact. 32.0% of domains collect network-error reports because a CDN switched it on; 2.2% collect their own CSP violations.
• The ceiling is reachable. The best 150 domains average 88.6 out of 100, against a corpus average of 28.0.

How does the web score overall?

Plot every domain by its overall score and the curve has one story to tell: it piles up near the bottom. Roughly six in ten sites land in the 20-to-40 band, and 86.1% score under 40 overall.

The crowding is sharper still inside that band. The 20-to-30 range alone holds over a third of the web (35.4%). Above 60 you find about 2% of sites, and the whole 90-to-100 range is 21 domains out of 521,442.

This is not a healthy population with a struggling tail. The struggling part is the population.

The waffle below puts the whole web in 100 squares, shaded by score band. Watch the block of red across the top: those are the two lowest bands, which together fill 86 of the 100 squares.

Each square is about 1% of all 521,442 domains, shaded by its overall-score band.

That curve is the rest of the report in one shape. Before reading it header by header, here is how each score was built.

How we measured this

Each of the 521,442 domains received a single anonymous GET request over HTTPS, and only its response headers were analyzed. The assessment is passive and non-intrusive: no payloads, no fuzzing, no state-changing requests.

Every header, policy and directive is checked on two separate 0-100 axes: security, does it protect, and quality, is it cleanly authored. Those two combine into the overall score.

Presence is not safety. A header being delivered and parseable is not the same as it being correct, and quality is a different question from security rather than a softer version of it.

A tidy Content-Security-Policy that still allows unsafe-inline scores high on quality and low on security. That single example is the whole report in one line.

How a domain is scored

We grade every header, directive, policy, reporting endpoint and attack concept on its own, from 0 to 100. Each one starts clean and loses points for the problems found on it, and the single worst problem sets its score.

How far a problem pulls a score down depends on its severity. Every finding lands in one of five levels, from an open hole to a gentle nudge:

Those per-item scores roll up into the category and overall scores by weight, so the controls that matter most for security count most. A weak script-src moves the needle far more than a missing Referrer-Policy, and the same weighting folds the relevant headers, directives and policies into each attack-resistance score.

One rule does the heavy lifting at the bottom of the scale. A required control that is simply missing scores 0 on that item, every time.

What separates a missing critical header from a missing minor one is not the score but the weight it carries. The mandatory one drags the total down hard; an optional one barely moves it.

What this data can and cannot tell you

Every number here describes response headers at scan time, from one request, from one place on the network. That is a real limit and it cuts in both directions, so it is worth stating plainly before the findings.

We under-count some protections. A site that sets a policy only on authenticated pages, or that varies headers by route, is judged on the one response we saw. Controls that live in HTML rather than headers, such as a meta-delivered policy on a page we did not fetch, are invisible to us.

We also under-count some risks. Header analysis cannot see whether a page loads an unpinned script, whether an inline handler bypasses the policy in practice, or whether a nonce is regenerated per response. A passing header is a floor, not a clean bill of health.

The population is what we scan, not a ranked sample of the web. It skews toward domains that resolve, answer on 443 and return a document, and it is not weighted by traffic. A figure here is a share of domains, never a share of page views.

One external check is worth having. The HTTP Archive's Web Almanac put CSP adoption at 21.9% of mobile home pages in 2025, measured on a different corpus with a different crawler; we measure 22.0%. The two do not have to agree, and the fact that they do is a reason to trust the shape of what follows.

Two axes, five severities, a weight on every control, and a stated limit on what a header can prove: that is the method. The sections that follow read its output, first the big attack classes, then header by header.

How exposed is the web to the big client-side attacks?

Roll every relevant header, directive and policy into one resistance score per attack class and the web's defenses nearly vanish. Every vector leaves 88% or more of sites exposed.

Full protection is a rounding error. Just 83 domains pass on script injection and 97 on data exfiltration; supply-chain tampering is stopped on a single domain in the entire corpus.

The relative exception is clickjacking, where 5.2% pass, and only because the fix is one old, simple header. Even there, almost nine sites in ten are open.

Each ring below rolls the headers, directives and policies that defend against one attack class into a single test, then counts a domain as exposed when that defense is missing or too weak. The green slice is the strict bar: only a full pass counts as protected.

Across all four classes the verdict is the same. Full protection is a rounding error everywhere, the one vector with real protection owes it to a single legacy header, and the resistance averages are propped up by partial defenses rather than by anyone closing the gap. The next section steps back from the attacks to ask which protective headers the web actually sends.

Which protective headers does the web actually send?

Rank the protective response headers by how many sites send them and you get a staircase down from the automatic to the deliberate. Cache-Control tops it at 68.4%, and it is there because performance tooling sets it rather than because anyone chose it.

The security headers proper sit in the middle, each on roughly two in five sites: X-Content-Type-Options at 42.2%, X-Frame-Options at 39.3%, Strict-Transport-Security at 38.8%. The cross-origin headers, which take real thought, fall to 1.4% at the bottom.

Adoption is only half the story. For most active headers, the sites that send them pass our checks: X-Content-Type-Options passes on 99.9% of its senders, and X-Frame-Options and Cross-Origin-Resource-Policy pass on every single one.

These headers are near-binary switches, though. Passing them is easy, so the real signal is how few sites send them at all. Referrer-Policy passes on 84.5% of its senders, Cache-Control on 85.6%.

One header breaks the pattern. Nearly two in five sites send Strict-Transport-Security, but fewer than half of those send it correctly: 42.3% of HSTS senders pass, while the rest ship a short max-age or skip includeSubDomains and preload.

That gap is the whole story of this section. Counted against the entire corpus, fully correct HSTS reaches just one site in six (16.4%). It is the one broadly adopted header where adoption and correctness come apart.

The first table below is that staircase: each active header by adoption and by how its senders score. The second lists the retired headers still in the wild, where sending them is the problem.

The header that makes browsers less safe

Most missing headers cost you protection. One header costs you protection by being there. X-XSS-Protection drove a browser feature, the XSS auditor, that every modern engine has since removed.

Turning it on (1 or 1; mode=block) created the very cross-site information leaks it was meant to stop. The only safe value left is 0, which switches the dead feature off.

Yet more than a fifth of the web still sends the header (21.2%, 110,371 sites). For these sites adoption is the regression: the fix is to delete the header, not configure it.

Worse, more than nine in ten of those senders use the unsafe enabled value (91.6%, 101,139 sites), the exact mode that was the reason browsers killed the feature.

The two tiles below read inverted. Presence is the failure, so adoption shows in amber, and the second tile is the share of senders stuck on the unsafe value.

How many domains still send X-XSS-Protection, and how many of those use the unsafe enabled value.

What your headers give away

Headers protect, but they also disclose. By default a lot of stacks announce themselves in the response: Server, X-Powered-By and their kin name the software, and often the exact version, running behind the site.

None of this is required to serve a page, and all of it shortens an attacker's work. Naming the technology narrows the search; naming the version turns the header into a direct lookup against published vulnerabilities for that release.

Roughly two in five sites name their stack (39.1%), and over half of those print the version too (54.9% of the disclosers), leaving about one site in five exposing the exact release it runs (21.5% of the whole corpus).

The two tiles below split that disclosure: the share of all sites that name their technology, and the narrower share that also leak the version.

Across the whole corpus, how many domains disclose their technology in a header, and how many also expose its version.

How safe are the cookies the web sets?

A cookie carries the session, so its flags decide how easily that session can be stolen or sent where it should not go. Three attributes do the work: Secure keeps the cookie off plaintext connections, HttpOnly hides it from JavaScript and so from an injected script, and SameSite controls whether it rides along on cross-site requests.

This figure counts cookies rather than sites. Across the 492,692 cookies in the corpus, about half carry each protective flag: Secure on 55.0%, HttpOnly on 49.5%, SameSite on 46.8%. Fewer than half declare SameSite at all.

The SameSite value is the sharper twist. Of the cookies that set it, most choose None, the value that opts back out of cross-site protection. At 49.7% it is the plurality, just ahead of Lax at 44.9% and far ahead of Strict at 5.3%.

So the modal hardened-cookie choice is the weakest one. Counted against every cookie in the corpus, None lands on about one in four (23.2%), while Strict stays a rounding error.

The table below shows the share of cookies using each flag, and the donut below it breaks down the SameSite value among those that set one.

Of the cookies in the corpus, the share setting each protective attribute, and the SameSite value chosen by those that set one.

Across all four figures the same fault repeats: a header sent is not a header set correctly. The easy headers are nearly perfect; the load-bearing ones are not. Where the value carries real security weight, HSTS, SameSite and the leftover retired headers show how often the choice works against the site.

That leads straight into the one control built to contain script injection, and how the web builds it.

How is Content-Security-Policy actually built?

Content-Security-Policy is the one control on the web that reliably contains script injection once it happens. About a quarter of sites send one, and almost none of those send a safe one.

The four donuts below frame the whole problem: how many domains ship a CSP, how those policies score on security, how they are delivered, and whether they enforce or only watch.

How many domains ship a Content-Security-Policy, how those policies score, and how they are delivered and enforced.

Adoption is the easy half. 22.0% of the web ships a CSP (114,974 of 521,442 domains), and those policies are clean: they average 98 out of 100 on quality.

Then the security check runs and the floor drops out. Of the policies we evaluate, 91.0% fail (104,675 sites) and only 4.4% pass (5,049 sites).

The same policies that score 98 on clean authoring average 29 on security. Clean, and useless.

These are real policies, not experiments. Almost all run in enforce mode rather than report-only (90.8%), and 96.0% arrive in a header, with only 2.6% relying on a meta tag alone. The header is present; the protection is not.

At corpus scale, a passing CSP exists on 0.97% of all domains. Less than one site in a hundred has the control that would contain the most common client-side attack.

Which directives do policies set, and how well?

A Content-Security-Policy is a list of directives, and they do not carry equal weight. Sites get the cheap ones right and the dangerous ones wrong.

frame-ancestors leads adoption at 54.8% of CSP sites and passes 76.8% of the time, because it does one narrow job. script-src, the directive that actually gates injected scripts, appears on 39.4% of CSP sites and fails 89.4% of the time (41,560 of 46,469 uses).

That pattern holds down the table. The directives that constrain scripts and styles fail hardest (style-src passes 8.2% of the time, script-src-elem 6.4%), while the structural ones pass easily: base-uri passes 85.5%, and upgrade-insecure-requests passes everywhere it appears.

The hard part of CSP is the two or three directives that actually contain an attack, not the act of listing them. The modern hardening directives barely register at the bottom of the table: require-trusted-types-for appears on 276 CSP sites, trusted-types on 144.

The table below ranks every canonical directive by how often it appears, then scores each one: of the times it is used, how many pass, partially pass, or fail. Watch the gap between the high-usage *-src directives and their failure rates.

How often each CSP directive appears in policies, and how well those uses score.

What hardens a policy, and what weakens it

Whether a policy protects comes down to the keywords inside it, and CSP authors reach for the wrong ones. The weakening keywords outnumber the hardening ones by a wide margin.

unsafe-inline shows up on 37.1% of CSP sites and unsafe-eval on 32.6%. Nonces, the headline hardening mechanism, reach 5.4%. Roughly seven times as many policies allow inline scripts outright as lock them down with a nonce.

It gets worse below the headline. strict-dynamic, the keyword that makes a nonce-based policy genuinely hard to bypass, sits on 2.7% of CSP sites (3,186 policies). Trusted Types, the strongest DOM-injection defense the platform offers, is enforced on 275.

The weakening list also runs deeper than the two famous keywords. More than one policy in five allows a known JSONP endpoint (22.5%) or a known script gadget (20.9%), both of which hand an attacker a way around an otherwise reasonable allowlist.

The two tables below split the mechanisms that harden a policy from the ones that weaken it, each as a share of CSP-delivering sites. Read them as a pair: the green column is short, the red column is not.

The mechanisms that strengthen a policy, each as a share of CSP-delivering domains.

The mechanisms that weaken a policy, each as a share of CSP-delivering domains.

What goes wrong in the policies that exist?

Even where policies are messy, the mess is mostly harmless. The most common authoring mistake reaches 12.3% of CSP sites, and it is carrying a deprecated directive copied from an old template.

Below it the list drops into single digits: a duplicate source value (8.2%), a keyword used in a directive that ignores it (6.1%), a source already covered by a broader one (5.9%). These are hygiene problems, not holes.

The ones with real teeth are rare, which is exactly why they survive. About one CSP site in 325 separates its directives with commas instead of semicolons, which throws no error a developer would ever see. It quietly collapses the policy into nonsense.

CSP gives authors almost no feedback, so these mistakes are never caught. Nothing in a browser tells you that your policy parsed into something you did not write.

The table below ranks the ten most common authoring mistakes by how many CSP sites they hit, as a share of CSP-delivering sites.

The most common authoring mistakes in the policies that exist, by how many CSP sites they hit.

CSP adoption is real, but a present header is not a working defense. Nine policies in ten fail, and the directives that stop script injection are exactly the ones authors get wrong. The next section steps back from CSP to ask how the other modern policies are deployed.

How widely are the other policies deployed?

The most-deployed policy on the web is not a security control. Network Error Logging reaches 32.0% of domains, ahead of Content-Security-Policy at 22.0%, and it gets there because CDNs switch it on rather than because operators chose it.

Below CSP the modern headers thin out fast. Permissions-Policy reaches 9.7% and COOP 8.7%, roughly one site in eleven. COEP, the second half of cross-origin isolation, lands on 0.8% of sites.

Because true isolation requires both COOP and COEP, that COEP figure is the real ceiling no matter how many sites set COOP alone. COEP is the scarcer of the pair by a factor of eleven, so almost every COOP deployment cannot reach isolation at all.

The genuinely new policies barely register. Document-Policy sits at 0.1% (584 domains), while Integrity-Policy and Connection-Allowlist are a literal handful, 10 domains and 3. These are shipped browser features with essentially no field adoption, a frontier worth naming so next year has a baseline.

The table below ranks each policy by the share of the corpus that deploys it, then splits each one by mode: enforce, both, or report-only. Notice that report-only is all but abandoned; every widely-set policy is enforced from day one.

How widely each modern policy is deployed, and for each one whether its deployers enforce it, run both modes, or only monitor it.

Deployment is only half the picture. The chart below shows, of the sites that deploy each policy, how many pass our security checks, land in partial, or fail outright, sorted so the worst failure rate sits on the left.

One bar stands apart. CSP fails on 91.0% of the policies that get evaluated and passes on 4.4%. Every other widely deployed policy passes almost every time it is set: Permissions-Policy at 100%, NEL effectively 100%, COOP at 94.8%.

COEP is the interesting middle case. It passes on only 15.6% of its deployers, with the other 84.4% landing in partial, because setting COEP without the COOP value that completes isolation gets you a header and not the guarantee.

Part of the CSP gap is what the policy can express. CSP is graded on a hard rubric, a rich allowlist that can be present yet insecure. The others are close to binary, where present and well-formed is a pass, so the contrast measures the difficulty of the policy as much as the operator's skill.

Read the smallest bars with care. The Document-Policy, Integrity-Policy and Connection-Allowlist rates rest on a few deployers each, not a population, so their bars are anecdotes, not trends.

Of the sites that deploy and can be evaluated for each policy, how many pass, partially pass, or fail our security checks. Bars are sorted by failure rate.

CSP is the one widely deployed policy that mostly fails. A fifth of the web reaches for it, keeps it clean enough to enforce, and still leaves it open. The next section asks who can even see those failures when they happen.

Can anyone actually see the violations?

On paper, about a third of the web is wired up to report problems back to its operators. Almost all of that is network-error logging, switched on automatically by CDNs rather than chosen by any site owner.

Strip the auto-enabled logging out and the deliberate signal is small. Network Error Logging is set up on 166,629 domains; every other report type a site would actually choose adds up to 17,494 domains between them.

The report that matters most is the rarest of the common ones. 2.2% of the corpus collects its own Content-Security-Policy violations: 11,526 domains, the only feedback that tells you your policy is breaking real pages.

Reporting is also the rare place where setup and delivery come apart, and the newer policies are where it breaks. Of the 1,596 domains that wire up COOP reporting, 89.8% have it broken, and COEP reporting is broken on 95.3% of the 1,523 that try.

CSP reporting is in better shape: 97.3% of the domains that set it up receive reports. The web is not watching its own violations, and where it tries on the newer policies it usually misconfigures the endpoint.

What counts as broken is worth stating precisely. A row is broken only when the policy names a destination the browser cannot deliver to; a policy that quietly falls back to the default group and finds nothing there is counted as not set up, never as broken.

That distinction is what sinks COOP and COEP. Neither can name a URL: both point at a report-to group that has to be declared separately in a Reporting-Endpoints header, so the ordinary failure is a line copied from a guide with its report-to="coop" intact and no group ever declared behind it.

CSP escapes most of this because report-uri names a URL inline, with no second header to forget. The gap between 97.3% working for CSP and 4.7% for COEP is largely that one design difference, not a difference in how carefully the two were set up.

The table below ranks each report type by the share of the corpus that sets it up, then splits each row into working and broken endpoints. Two denominators sit side by side: the set-up share is of the whole corpus, but the working-versus-broken split is of that row's own set-up count.

Each report type by the share of the corpus that sets it up. The working and broken columns split each row's own set-up count, not the corpus.

Report-To or Reporting-Endpoints?

There are two ways to tell a browser where to send reports. Reporting-Endpoints is the current standard; Report-To is the older header it replaced and is now deprecated.

The donut below looks only at the sites that declare either header, and the balance is lopsided. Of those sites, 97.5% still use the deprecated Report-To, and 2.5% have moved to the modern header.

That deprecated slice is the same CDN plumbing already counted above. Report-To sits on 32.3% of the corpus, the same share as network-error logging, because they are one CDN-injected mechanism rather than a choice made site by site.

The modern Reporting-Endpoints has barely landed: 4,281 sites, 0.8% of the corpus, roughly one site in 122.

Of the domains that declare a reporting-destination header, the split between the modern Reporting-Endpoints and the deprecated Report-To.

The web cannot see what it does not watch. Outside the logging CDNs switch on for it, deliberate reporting barely registers, and on the newest policies most of the sites that try get the endpoint wrong. The next section turns from diagnosis to prescription.

What should you fix first?

149 distinct findings is not a plan. Weight each one by how much damage it does and how many sites it reaches, and a short priority list falls out.

The three highest-severity recommendations all reduce to one sentence: ship a real CSP. The script-injection (99.2%), supply-chain (98.9%) and data-exfiltration (98.4%) findings each reach roughly 99% of sites.

All three are the same condition wearing three hats. A page with no real CSP restricts nothing, so it fails all three at once. That makes the highest-leverage move on the web also the most basic: deploy a policy, then tighten it.

Below those headline findings the list changes character. The fixes for sites that already have a CSP but weakened it reach far fewer domains: about one in six still lets object-src load plugins (18.0%) or leaves base-uri open (18.0%), and 17.3% let connect-src exfiltrate freely.

After that come the cheap missing-header recommendations that reach almost everyone but rarely raise the stakes, and finally the emerging policies almost no one ships.

One thing is worth stating because of what it is not. The catalogue contains no critical findings this year. Nothing in the corpus fires our top severity, and the damage is carried entirely by 22 high-severity findings, three of which reach nearly every site on the web.

The table below ranks the top recommendations by relevance, damage times reach, so the most damaging and most widespread fixes sit first.

149 findings weighted by severity and reach, the highest-leverage fixes first.

The whole catalogue collapses to one priority: get a real CSP in place, then close the directives that weaken the policies that already exist. Everything else is the long tail. The next section steps back from the failures to ask what the best-configured sites do differently.

How far apart are the best and the rest?

A small elite proves a near-perfect score is reachable. The best 150 domains average 88.6 out of 100; the whole corpus of 521,442 averages 28.0. That is a 60.6-point gap, more than three times the typical score.

Split that gap by axis and it turns out to be one axis. On quality the two populations are almost indistinguishable: 96.2 for the best cohort against 95.8 for everyone else, a difference of less than half a point.

On security they are not the same web. The best cohort averages 89.0 out of 100 against the corpus average of 28.2, and that single axis carries the entire 60.6-point gap.

So the elite are not tidier than everyone else. They are protected, and everyone else is not, while both keep their configuration in much the same order.

The three cards below compare the best-configured cohort against the whole corpus on the overall score. The section that follows breaks that one number down area by area.

The best-configured 150 domains against all 521,442, on the overall 0-100 score.

Where the best pull ahead, area by area

The cards above compare the two populations on one number; these radars show where the difference actually sits. Each one sets the best-configured cohort of 150 sites against the average across all 521,442 domains, every spoke a 0-100 sub-score.

The two series are not the same size. Green is fewer than 1 site in 3,400. Amber is the whole web, the real baseline.

The same shape repeats in every panel: a green ring pushed out near the rim, sitting on a collapsed amber core. The gap is categorical, not incremental.

On CSP the best cohort scores 98 against the average's 5, a twentyfold split and the widest of all. Attack resistance runs 80 against 18, and the policy headers 59 against 13, four to five times the average in both cases.

Two areas read against that grain. Security headers is the one place the average looks respectable at 74 out of 100, and only because the cheap headers nearly everyone already sends prop it up.

Reporting setup is the opposite. Even the best cohort scores 9 out of 100, so this is the one axis where being best still means almost nobody bothers. Read a spoke near zero with care: it can mean the control is simply absent, and where the best cohort sits at zero on a deprecated directive, dropping it is the correct move.

The best sites settle the report's central question. A strict, secure posture is fully buildable, and a 1-in-3,400 sliver of the web has built it. The distance to everyone else is not a matter of tuning. It is the distance between sending a header and maintaining a whole policy, the same quality-high, security-low split traced here from the first chart to the last.

---