Research

Published September 13, 2026 · 761,367 domains scanned

State of the Web 2026

Key findings

• Almost nothing resists script injection. 108 domains out of 761,367 pass, and 99.3% are exposed.
• One site in five ships a Content-Security-Policy; 1.5% of those policies pass. A passing CSP exists on 0.29% of all domains.
• Nonces have not landed. 5.3% of policies use one, against 38.1% that still allow unsafe-inline.
• Reporting is a CDN artifact. 33.7% of domains collect network-error reports because a CDN switched it on; 1.9% collect their own CSP violations.
• The ceiling is reachable. The best 150 domains average 92.4 out of 100, against a corpus average of 46.0.

How does the web score overall?

Plot every domain by its overall score and the curve has one story to tell: it bunches in the middle and never climbs. Six in ten sites land in the 40-to-60 band, a third sit below it, and 93.4% score under 60 overall.

Both ends are nearly empty. Not one domain in the corpus scores below 20, but only 6.6% clear 60, and the whole 80-to-100 band is 3,051 domains out of 761,367, four in every thousand.

That middle bulge is the two axes averaging out: near-perfect authoring dragged down by security that barely registers. A 46 is not half-protected. It is well-formed and open.

The waffle below puts the whole web in 100 squares, shaded by score band. Watch how little green there is: 33 red squares and 61 amber ones carry the whole population, and just 6 squares reach past 60.

Each square is about 1% of all 761,367 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.

To place a single domain on that curve, compare it against the same corpus with the scanner that produced these numbers.

How we measured this

Each of the 761,367 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 19.4% over a larger and broader population. Two independent crawls landing within two and a half points of each other 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. Three of the four vectors leave more than 97% of sites exposed.

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

The one exception is clickjacking, where 7.1% pass and another third hold a partial defense, and only because the fix is one old, simple header. Even there, three sites in five 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 66.2%, 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 39.9%, X-Frame-Options at 37.3%, Strict-Transport-Security at 34.0%. The cross-origin headers, which take real thought, fall to 1.2% 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 on 98.6%. Cross-Origin-Resource-Policy is the exception: only 57.6% of its senders pass. More than four in ten set it to cross-origin, which grants exactly what sending no header at all grants, so the header is present and the protection is not.

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 86.7% of its senders, Cache-Control on 86.8%.

One header breaks the pattern. A third of all sites send Strict-Transport-Security, but barely one sender in five sends it correctly: 22.1% of HSTS senders pass, while the rest ship a short max-age or skip includeSubDomains and preload. A further 8,380 sites send it with max-age=0, which switches the protection off outright.

That gap is the whole story of this section. Counted against the entire corpus, fully correct HSTS reaches just one site in 13 (7.5%). 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 same checks run on demand: test the headers your own site sends.

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 nearly a fifth of the web still sends the header (18.6%, 141,522 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.0%, 128,730 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.4%), and over half of those print the version too (56.1% of the disclosers), leaving about one site in five exposing the exact release it runs (22.1% 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 672,987 cookies in the corpus, about half carry each protective flag: Secure on 54.3%, HttpOnly on 49.6%, SameSite on 45.5%. Fewer than half declare SameSite at all.

The SameSite value is the sharper twist. Of the cookies that set it, Lax is the plurality at 48.8%, but None, the value that opts back out of cross-site protection, sits right behind it at 45.7%, and Strict is a rounding error at 5.4%.

So the hardened-cookie choice is close to a coin flip between the safe default and the opt-out. Counted against every cookie in the corpus, None still lands on about one in five (20.8%), while Strict stays negligible.

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 one site in five sends 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. 19.4% of the web ships a CSP (148,000 of 761,367 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.4% fail (135,303 sites) and only 1.5% pass (2,251 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 (89.5%), and 96.0% arrive in a header, with only 2.7% relying on a meta tag alone. The header is present; the protection is not.

At corpus scale, a passing CSP exists on 0.29% of all domains. Fewer than three sites in a thousand have the control that would contain the most common client-side attack.

The gap between authoring quality and security is what a policy written by hand looks like. Building one from real browser reports closes it, because the directives come from what your visitors actually load.

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.9% of CSP sites and passes 76.9% of the time, because it does one narrow job. script-src, the directive that actually gates injected scripts, appears on 40.5% of CSP sites and fails 89.1% of the time (45,390 of 50,916 uses).

That pattern holds down the table. The directives that constrain scripts and styles fail hardest (style-src passes 9.3% of the time, script-src-elem 2.7%), while the structural ones pass easily: base-uri passes 91.6%, 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 285 CSP sites, trusted-types on 166.

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 38.1% of CSP sites and unsafe-eval on 33.0%. Nonces, the headline hardening mechanism, reach 5.3%. 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.5% of CSP sites (3,853 policies). Trusted Types, the strongest DOM-injection defense the platform offers, is enforced on 348.

The weakening list also runs deeper than the two famous keywords. More than one policy in five allows a known JSONP endpoint (22.1%) or a known script gadget (21.2%), 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 8.1% of CSP sites, and it is a source value listed twice in the same directive.

Below it the list stays in single digits: a keyword used in a directive that ignores it (6.2%), a source already covered by a broader one (6.1%), a deprecated directive copied from an old template (4.3%). These are hygiene problems, not holes.

The ones with real teeth are rare, which is exactly why they survive. About one CSP site in 89 writes a keyword without its quotes (1.1%), so unsafe-inline or self is parsed as a hostname and the directive quietly means something the author never wrote.

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 33.7% of domains, ahead of Content-Security-Policy at 19.4%, and it gets there because CDNs switch it on rather than because operators chose it.

Below CSP the modern headers thin out fast. COOP reaches 9.8% and Permissions-Policy 9.1%, roughly one site in eleven. COEP, the second half of cross-origin isolation, lands on 0.6% 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 seventeen, so almost every COOP deployment cannot reach isolation at all.

The genuinely new policies barely register. Document-Policy sits at 0.1% (720 domains), while Integrity-Policy and Connection-Allowlist are a literal handful, 16 domains and 6. 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.4% of the policies that get evaluated and passes on 1.5%. Every other widely deployed policy passes almost every time it is set: Permissions-Policy at 100%, NEL at 100%, COOP at 90.9%.

COEP is the interesting middle case. It passes on only 19.9% of its deployers, with the other 80.1% 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 256,658 domains; every other report type a site would actually choose adds up to 19,907 domains between them.

The report that matters most is the rarest of the common ones. 1.9% of the corpus collects its own Content-Security-Policy violations: 14,197 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,112 domains that wire up COOP reporting, 81.3% have it broken, and COEP reporting is broken on 92.4% of the 1,005 that try.

CSP reporting is in better shape: 97.5% 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.5% working for CSP and 7.6% 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, 98.1% still use the deprecated Report-To, and 1.9% have moved to the modern header.

That deprecated slice is the same CDN plumbing already counted above. Report-To sits on 34.1% of the corpus, near enough 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: 5,065 sites, 0.7% of the corpus, roughly one site in 151.

Wiring it up is one response header, and collecting what browsers send back is where the numbers in this section come from.

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?

157 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.6%) 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 site in seven leaves connect-src open enough to exfiltrate freely (15.1%), and 7.4% still allow unsafe-inline in script-src.

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 21 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.

157 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 92.4 out of 100; the whole corpus of 761,367 averages 46.0. That is a 46.4-point gap, as large again as the typical score.

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

On security they are not the same web. The best cohort averages 90.9 out of 100 against the corpus average of 29.2, a chasm of 61.5 points. The entire distance between the two populations sits on that one axis.

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 761,367, 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 761,367 domains, every spoke a 0-100 sub-score.

The two series are not the same size. Green is fewer than 1 site in 5,000. 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 7, a fourteenfold split and the widest of all. Attack resistance runs 88 against 23, and the policy headers 61 against 15, roughly four times the average in both cases.

Two areas read against that grain. Security headers is the one place the average clears half, at 54 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 8 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 rather than badly configured.

The best sites settle the report's central question. A strict, secure posture is fully buildable, and a 1-in-5,000 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.

---