Defaults.Exposed

Defaults.Exposed › Reports

The Isolation Headers: Why COOP, COEP, and CORP Cover Less Than 1% of the Web

Published

The Isolation Headers: Why COOP, COEP, and CORP Cover Less Than 1% of the Web

In August 2026, after more than four years of browser vendor urgency and published guidance, the three headers that enable cross-origin process isolation remain present on fewer than one in a hundred domains. The defaults.exposed census measured them across 376,928,750 domains: Cross-Origin-Opener-Policy (COOP) appeared on 2,951,559 (0.78%), Cross-Origin-Embedder-Policy (COEP) on 1,816,347 (0.48%), and Cross-Origin-Resource-Policy (CORP) on 2,442,653 (0.65%).

These are not obscure, experimental headers. They are the primary browser-level defence against Spectre-class side-channel attacks, a class of hardware vulnerability that has been public knowledge since January 2018 and that affects virtually every modern processor in production today.

The Problem the Headers Solve

The Spectre vulnerability, disclosed by Project Zero in January 2018 alongside Meltdown, demonstrated that hardware-level speculative execution could be exploited by JavaScript running in a browser tab to read memory from other processes. The attack required two conditions: the ability to execute JavaScript, and the ability to measure timing at high resolution.

Browser vendors responded by disabling high-resolution timers (including SharedArrayBuffer, which can be used to construct one), which broke legitimate use cases including WebAssembly threading. The long-term fix was process isolation: ensuring that cross-origin content runs in separate operating system processes where memory cannot be shared across origins at the hardware level.

The three headers operationalise this at the HTTP layer:

Cross-Origin-Opener-Policy (COOP) controls whether a document opened via window.open() retains a reference to its opener. Without COOP, a malicious page opened from a trusted page can navigate the opener to an attacker-controlled URL. COOP: same-origin breaks that link, isolating the browsing context group. Defined in the HTML Living Standard, Section 7.1.

Cross-Origin-Embedder-Policy (COEP) requires that all resources loaded by a document opt in to being embedded cross-origin, via the CORP header or a CORS response. Without COEP, a document can load arbitrary cross-origin resources as a covert channel for side-channel attacks. COEP: require-corp establishes the embedding boundary.

Cross-Origin-Resource-Policy (CORP) is the opt-in that resources set to declare whether they can be loaded cross-origin. Defined in the Fetch Standard, Section 3.7.

When a document sets both COOP: same-origin and COEP: require-corp, it achieves cross-origin isolation. The browser then re-enables SharedArrayBuffer and high-resolution timers for that document, because the process boundary means Spectre-class attacks cannot reach cross-origin memory. This is the intended end state. The headers are not defensive in isolation: all three must be co-ordinated.

Why the Numbers Are Low

Two primary constraints explain the adoption gap.

The COEP compatibility problem. COEP: require-corp means that every resource loaded by the document (images, scripts, fonts, iframes, videos) must either be same-origin or must explicitly set CORP on its response. Historically, most CDN-hosted resources, analytics scripts, advertising tags, and third-party embeds did not set CORP. Applying COEP to a production site would break any dependency that had not yet opted in.

This created a coordination problem at web scale. A site operator could not unilaterally apply COEP without auditing and confirming every external dependency. For sites with large dependency graphs, that audit could take months. The result is that early adoption of COEP was concentrated in sites with tightly controlled dependency sets: development tools, documentation sites, companies with controlled CDN stacks.

The August 2026 figure of 1.8 million COEP deployments (0.48%) is consistent with this dynamic. Progress has been made, but the web at large has not crossed the threshold.

The COOP popup-communication break. COOP: same-origin prevents communication between a page and popups it opens from different origins. This breaks OAuth flows, payment popups, and social login implementations that rely on cross-origin postMessage from a popup back to the opener. COOP: same-origin-allow-popups is a partial mitigation, allowing popup communication while still restricting opener access from navigated-away contexts, but it provides weaker isolation guarantees than same-origin.

Sites that implement OAuth-based login, payment widgets, or social sign-in via popups face a real engineering cost to adopt COOP. The 2.9 million COOP deployments (0.78%) include a mix of same-origin and same-origin-allow-popups, and the effective cross-origin isolation rate (requiring both COOP and COEP in their strict forms) is lower still.

Who Has Deployed

The adoption signature visible in the census data is characteristic of developer-facing infrastructure:

The isolation headers are not primarily a consumer web feature. A marketing site that loads ten analytics tags, three advertising pixels, a social sharing widget, and a payment form is a poor candidate for COEP adoption until all of those dependencies ship CORP headers. That is a function of the dependency vendors, not the site operator.

The gap between CORP (2.4 million) and COEP (1.8 million) is meaningful. Some operators have deployed CORP on their resources to unblock others from deploying COEP, without applying COEP themselves. This upstream-first adoption pattern is rational: fixing the bottleneck for others costs little and enables the ecosystem to move.

The Regulatory and Framework Context

No major regulatory framework currently requires COOP, COEP, or CORP explicitly. The OWASP Secure Headers Project lists COOP and CORP in its recommendations. CISA’s Known Exploited Vulnerabilities catalogue includes Spectre-adjacent JavaScript engine vulnerabilities, though the header-level mitigation is not referenced in KEV remediation guidance.

The absence of a regulatory requirement is relevant to adoption velocity. The headers that have seen strong deployment growth, HSTS and Content-Security-Policy, both have clear compliance-driven adoption pathways. HSTS is required by NIST SP 800-52 Rev 2 for US federal systems and by UK Cyber Essentials-aligned guidance. CSP is referenced in multiple PCI-DSS requirements. COOP, COEP, and CORP have no equivalent forcing function in current frameworks.

This will likely change as Spectre-class attacks mature. The academic and vulnerability research literature has continued to identify new timing-based side channels in browser engines since 2018. The headers are the correct long-term mitigation direction endorsed by all major browser vendors. They are in the specification. The question is whether operator adoption reaches meaningful scale before a widely-exploited variant forces the issue.

The Path Forward

For site operators that can realistically adopt these headers, the recommended sequence is:

  1. Audit cross-origin dependencies. Every script, image, font, and iframe loaded from a different origin needs to be inventoried. Anything without a CORP header on its response is a blocker for COEP.

  2. Deploy CORP on your own resources first. Any resource your own infrastructure serves should set CORP: same-site or CORP: cross-origin as appropriate. This removes your properties as blockers for others.

  3. Deploy COOP: same-origin-allow-popups as a starting posture, progressing to same-origin once OAuth and payment flows are audited.

  4. Apply COEP: credentialless as a stepping stone. Defined in a later browser specification, COEP: credentialless allows cross-origin loads without CORP, at the cost of those resources losing their credentials (cookies, tokens). This is a more forgiving intermediate posture for sites with uncontrolled dependency graphs.

  5. Test in staging with Reporting-Endpoints and COEP: report-only before enforcement.

Check whether your domain has deployed these headers using the defaults.exposed scanner, which measures all three against the August 2026 census baseline.

What this means for security teams and web application owners

The sub-1% adoption of COOP, COEP, and CORP is not evidence that Spectre-class attacks are rare or not a concern — it reflects how genuinely hard these headers are to deploy on sites with complex third-party dependency graphs. Security teams assessing their own posture should separate the question “are these headers required?” from “can we realistically deploy them today?”

For most organisations, the honest answer to the second question is: not without engineering work. A site that loads analytics, advertising, social widgets, and payment iframes from multiple third-party domains cannot deploy COEP: require-corp until all those dependencies ship CORP on their responses — and many do not. That is not a reason to deprioritise the work indefinitely; it is a reason to start the dependency audit now and track progress, because the ecosystem is slowly moving in the right direction and being behind when regulatory or framework requirements land is worse than being early.

For organisations with tightly controlled dependency stacks — developer tools, API documentation, internal applications, sites where the team owns both the document and all loaded resources — the adoption barrier is lower. COEP: credentialless, introduced after the original specification, substantially reduces the compatibility cost and is the recommended starting posture for these sites today. If your site uses WebAssembly threading or needs SharedArrayBuffer, cross-origin isolation is not optional — it is the only path to re-enabling those APIs in current browsers.

The gap between CORP (0.65%) and COEP (0.48%) tells an important story: some operators are already doing the upstream work, shipping CORP on their own resources to unblock others. If your organisation serves shared scripts, fonts, or assets consumed by other sites, adding CORP headers now costs almost nothing and contributes to the ecosystem condition that makes COEP viable at broader scale.

Data to cite

FAQ: Cross-Origin Isolation Headers in 2026

What are COOP, COEP, and CORP and why do they matter? COOP (Cross-Origin-Opener-Policy), COEP (Cross-Origin-Embedder-Policy), and CORP (Cross-Origin-Resource-Policy) are the three HTTP response headers that together enable cross-origin process isolation in browsers. This isolation is the primary defence against Spectre-class side-channel attacks, which have been public knowledge since 2018 and affect virtually all modern processors. Without these headers, malicious JavaScript in one browser tab can potentially read memory from other processes on the same machine.

Why has adoption remained below 1% after four years of browser vendor guidance? Two main reasons. First, COEP requires that every third-party resource a site loads — analytics scripts, advertising tags, fonts, payment iframes — must set CORP on its responses, creating a coordination problem across the entire web dependency graph. Second, COOP breaks OAuth popup flows, payment widgets, and social sign-in implementations that rely on cross-origin popup communication. Sites with complex third-party dependencies face real compatibility costs before they can adopt these headers safely.

What should I do about these headers on my own site? Start with a dependency audit: list every cross-origin resource your pages load. If you control the resources (your own CDN, assets, APIs), add CORP headers to them immediately — this costs almost nothing and helps others. For the document itself, try COEP: credentialless as an intermediate posture before COEP: require-corp. Deploy COOP: same-origin-allow-popups first, then progress to same-origin once you have verified your OAuth and payment flows work. Test everything in staging with report-only mode before enforcing.

How does this compare to adoption of other security headers like HSTS and CSP? Very differently. HSTS is deployed on 43.8% of HTTPS domains and CSP on 8.0% of measurable domains in the same August 2026 census. Both HSTS and CSP have explicit compliance requirements in frameworks like NIST SP 800-52, UK Cyber Essentials, and PCI-DSS — which drives adoption. COOP, COEP, and CORP have no equivalent regulatory forcing function yet, which is the primary structural reason for the gap.

Why does this matter for organisations running web applications? If your web application handles sensitive data and runs in a context where Spectre-class attacks are a realistic threat model — particularly applications accessible from shared or untrusted devices — cross-origin isolation is the correct long-term mitigation direction endorsed by all major browser vendors. Waiting for regulatory requirements to land before starting the dependency audit puts organisations in a reactive position. Starting now, even with CORP on your own resources as the first step, builds the foundation for faster adoption when the framework pressure arrives.

Check your domain free at defaults.exposed — see whether your domain has deployed COOP, COEP, and CORP, alongside 31 other externally observable security checks. Takes 30 seconds. No account needed. Read the flagship State of Domain Security 2026 report.

How to cite this report

Press / blog: defaults.exposed (2026). The Isolation Headers: Why COOP, COEP, and CORP Cover Less Than 1% of the Web. defaults.exposed August 2026 Domain Security Census (432,127,908 domains scanned, asOf 2026-08-16). Retrieved from https://defaults.exposed/en/articles/cross-origin-isolation-headers-coop-coep-corp-2026

Academic: defaults.exposed. (2026, August 18). The Isolation Headers: Why COOP, COEP, and CORP Cover Less Than 1% of the Web. In defaults.exposed Domain Security Census: August 2026. https://defaults.exposed/en/articles/cross-origin-isolation-headers-coop-coep-corp-2026

In-line citation: (defaults.exposed, August 2026 Domain Security Census, n=376,928,750 graded 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

Data source: defaults.exposed August 2026 census, methodology v9, as of 2026-08-16. 376,928,750 domains graded from approximately 432 million scanned. References: HTML Living Standard Section 7.1 (COOP), Fetch Standard Section 3.7 (CORP), Spectre vulnerability disclosure (Project Zero, January 2018), OWASP Secure Headers Project, W3C Cross-Origin-Embedder-Policy specification.