In 2018, researchers demonstrated the Spectre vulnerability — a CPU-level attack where malicious JavaScript on one page could read memory from another page in the same process. The browser vendors' response was swift and far-reaching: they disabled SharedArrayBuffer across all browsers, reduced the precision of performance.now(), and effectively killed any JavaScript API that could be used as a high-resolution timer for timing attacks.
Then they brought those APIs back, but only for pages that opt into Cross-Origin Isolation. The idea: if your page proves it's not loading any cross-origin resources that haven't explicitly consented to being embedded, then Spectre attacks can't leak data from those resources, and the powerful APIs are safe to re-enable.
The catch is that most developers have never heard of Cross-Origin Isolation, and the pages that need SharedArrayBuffer (WASM-heavy apps, video editors, CAD tools, game engines compiled to WebAssembly) are the ones most likely to embed third-party resources that break isolation.
The three headers
Cross-Origin Isolation requires three HTTP headers working together:
Cross-Origin-Opener-Policy (COOP): same-origin. This tells the browser that your page should not share a browsing context group with cross-origin pages. In practice, it means that if another site opens your page in a window (or vice versa), they can't access each other's window object. This prevents Spectre-style attacks through window.opener references.
Cross-Origin-Embedder-Policy (COEP): require-corp. This tells the browser that every subresource your page loads must either be same-origin or explicitly opt in to being embedded via Cross-Origin-Resource-Policy: cross-origin. If any resource doesn't have that opt-in, the browser blocks it.
Cross-Origin-Resource-Policy (CORP): cross-origin. This is the opt-in from the resource side. When a CDN or API server sends CORP: cross-origin, it's saying "yes, any page can embed me, even cross-origin-isolated pages."
When all three are correct, the browser sets self.crossOriginIsolated = true, and SharedArrayBuffer, performance.measureUserAgentSpecificMemory(), and high-resolution timers become available.
Why this is hard to deploy
The difficulty isn't setting the headers on your own server. That's two lines of config. The difficulty is that COEP require-corp breaks every third-party resource that doesn't send CORP: cross-origin.
Load Google Fonts? Blocked. Embed a YouTube iframe? Blocked. Use a third-party analytics script? Blocked. Load images from a CDN that doesn't set CORP headers? Blocked.
Every single cross-origin resource on your page needs to either set CORP: cross-origin or be loaded with the crossorigin attribute on the HTML element. Since you don't control third-party servers, you're at their mercy. Google Fonts does set the right headers. Many other services don't.
There's a middle ground: COEP: credentialless (shipped in Chrome 96). This is a less strict mode that allows cross-origin resources to load without CORP headers, as long as the request doesn't include credentials (cookies, client certificates). It breaks fewer things while still enabling isolation for most use cases.
What the tool checks
The Cross-Origin Isolation Audit examines your page's response headers for all three policies. It reports:
- Whether
COOPis set and to what value (same-origin,same-origin-allow-popups,unsafe-none) - Whether
COEPis set and to what value (require-corp,credentialless, or missing) - Whether
CORPis set on the main document - Whether the combination would result in
crossOriginIsolated = true - Which subresources might break under
COEP: require-corpbecause they lack CORP headers
If you're building a WASM application and wondering why SharedArrayBuffer isn't available in production, this audit will tell you exactly which header is missing or misconfigured.
When you actually need this
Most websites don't need Cross-Origin Isolation. If you're running a blog, an e-commerce store, or a marketing site, you don't use SharedArrayBuffer and you don't need precise timers. Adding COEP would break your Google Fonts and analytics scripts for no benefit.
You need Cross-Origin Isolation if you're building:
- WebAssembly applications that use threading (Emscripten with
-pthread) - Browser-based video or image editors with real-time processing
- Games compiled from C++ to WASM that use shared memory
- Scientific computing or CAD tools that run in the browser
- Any application that explicitly needs
SharedArrayBuffer
For those use cases, the audit helps you identify exactly what's blocking isolation so you can fix it systematically rather than guessing which third-party resource is the problem.
If you're deploying a WASM-based tool or application and want to understand the server configuration that makes it work, The $97 Launch on Kindle covers the hosting and header configuration from the ground up.
Fact-check notes and sources
- Spectre vulnerability and browser mitigations: Google Security Blog, "A Spectre proof-of-concept for a Spectre-proof web"
- SharedArrayBuffer gating behind Cross-Origin Isolation: MDN Web Docs, "SharedArrayBuffer"
- COEP credentialless mode: Chrome Platform Status, "COEP: credentialless"
- COOP/COEP explainer: web.dev, "Making your website cross-origin isolated"
Related reading
- CORS headers audit — CORS policies interact directly with Cross-Origin Isolation
- CSP header audit — Content Security Policy is the other major browser security header
- Response header audit — check all security response headers in one pass
- Subresource integrity audit — another layer of cross-origin resource verification
This post is informational, not security-consulting advice. Mentions of Google, Chrome, and MDN are nominative fair use. No affiliation is implied.
