Cross-Origin Isolation
Cross-origin isolation uses COOP and COEP headers to place a page in an isolated browsing context group, unlocking SharedArrayBuffer and threaded WebAssembly at the cost of strict embedding rules.
Definition
Cross-origin isolation is a page state achieved by sending Cross-Origin-Opener-Policy: same-origin and Cross-Origin-Embedder-Policy: require-corp. The page then runs in its own browsing context group where cross-origin windows cannot reach it and every embedded subresource must opt in via CORP or CORS, enabling high-resolution timers and SharedArrayBuffer-backed threading.
Context and scope
Required by measurement libraries, WebAssembly threads, and tools that postMessage large buffers between workers. Applied to applications such as editors, IDEs in the browser, and emulators.
Common misconceptions
- Isolation is default — pages are open to cross-origin openers and embeds unless these headers are sent
- COEP only guards iframes — it covers images, scripts, styles, fonts, and every embedded subresource
- Enabling the headers is transparent to the site — third-party embeds without CORP break immediately
Anti-patterns
- Turning on require-corp on a page full of third-party pixels, widgets, and ads without a CORP proxy
- Trying to use SharedArrayBuffer or WASM threads without checking the isolation state in production
- Setting COOP to same-origin-allow-popup and expecting full isolation semantics for the opener relationship
Related concepts
Related examples
Authoritative source
https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Cross-Origin-Opener-Policy
What it is
Two headers cooperate: COOP cuts the window opener relationship so an opened page cannot access the opener and vice versa; COEP requires that every cross-origin resource the page embeds explicitly grants permission through CORP or CORS. Together they place the page in an isolated group.
How it works
With both headers set, the browser exposes a process-level separation and unlocks crossOriginIsolated, which gates SharedArrayBuffer, precise timers, and multi-threaded WebAssembly. Embedded resources must serve Cross-Origin-Resource-Policy or proper CORS headers, or the page fails to load them under require-corp.
When to use it
Compute-heavy in-browser applications: code editors, emulators, audio and video processing pipelines, and performance measurement SDKs that need monotonic high-resolution timing. A CORP header on your own CDN resources makes first-party embedding seamless.
Pitfalls
Third-party resources without CORP break hard, so rollouts need an inventory of every embedded origin. credentialless COEP mitigates image use cases. Feature-detect crossOriginIsolated rather than assuming the header pair survived every proxy.