COOP and COEP Turn Cross-Origin Isolation into a Document-Group Boundary
A web page can be same-origin with its own application code while still maintaining relationships with cross-origin popups, frames, workers, and resources. Those relationships matter when a browser decides which documents can occupy the same browsing context group and which capabilities can be exposed safely.
Cross-origin isolation changes that arrangement through two response policies with different jobs. Cross-Origin-Opener-Policy (COOP) controls top-level opener relationships and browsing context group switches. Cross-Origin-Embedder-Policy (COEP) constrains the cross-origin resources a document and its descendants may load. Used together in the configuration required for isolation, they establish a browser-enforced boundary that is broader than the same-origin policy alone.
COOP changes the top-level browsing context group
The HTML Standard defines COOP as a policy attached to a top-level document. With Cross-Origin-Opener-Policy: same-origin, a navigation can force a new top-level browsing context and group when the relevant origins and opener policies do not match.
That group switch affects the relationship represented through window.opener. A cross-origin popup that lands outside the opener’s group no longer retains the same live opener relationship that an unsafe-none arrangement permits.
This is not equivalent to blocking navigation. A link or script can still open another origin when other browser policy permits it. COOP changes the grouping and opener relationship around that navigation. It is therefore an isolation control, not a URL allowlist.
The distinction also matters for same-origin-allow-popups. That value preserves more compatibility with popups that use the default policy. It does not produce the same isolation state as the same-origin value combined with a compatible COEP.
COEP constrains what enters the isolated environment
COEP operates on a different edge of the boundary. A document using Cross-Origin-Embedder-Policy: require-corp cannot freely embed arbitrary cross-origin resources in no-cors mode. Such resources need an applicable Cross-Origin-Resource-Policy response or need to be fetched through CORS where that mode is appropriate.
This restriction is significant because an isolated top-level document is not isolated merely by severing opener relationships. Its execution environment can still depend on scripts, images, workers, fonts, and other responses from different origins. COEP makes those dependencies participate in an explicit resource-sharing policy.
The browser performs the enforcement. Application code does not get to load a disallowed response and then decide whether to trust it. A response that fails the applicable embedder checks is blocked from becoming an embedded resource in the protected environment.
credentialless is another COEP value compatible with cross-origin isolation. Its resource-loading semantics differ from require-corp: in relevant no-cors cross-origin requests, credentials are omitted rather than requiring every such response to opt in through CORP. Deployments cannot treat the two values as textual aliases even though both can participate in the isolation state.
The isolation state depends on both policy dimensions
The HTML processing model derives a special opener-policy state when a top-level document has COOP same-origin and a COEP value compatible with cross-origin isolation. A browsing context group created under that state receives a cross-origin isolation mode.
That coupling prevents a misleading configuration in which opener separation is present but embedded cross-origin content remains unconstrained. It also prevents COEP alone from being treated as a complete top-level opener boundary.
A minimal response shape commonly associated with the stricter combination is:
Cross-Origin-Opener-Policy: same-origin
Cross-Origin-Embedder-Policy: require-corpThose headers do not state that every subresource will load successfully. Existing cross-origin dependencies may fail unless their responses and fetch modes satisfy the resulting embedder policy. The operational cost is therefore visible at integration boundaries: CDNs, image hosts, font services, worker scripts, and other origins may need compatible response policy.
Isolation is stronger than same-origin access checks but narrower than a site sandbox
The same-origin policy primarily restricts script access across origins. COOP and COEP add constraints around grouping and resource embedding, but they do not turn a site into a general-purpose sandbox.
Same-origin documents can still have relationships permitted by the platform. The HTML Standard also notes that severing an opener relationship does not by itself create a robust security boundary between same-origin documents. Application-level trust within an origin remains relevant.
Likewise, cross-origin isolation does not replace Content Security Policy. CSP can restrict script sources, frame destinations, connections, and other resource classes according to its directives. COEP is concerned with whether cross-origin resources are eligible to enter the embedded environment under its policy. The controls can coexist because they govern different decisions.
Cross-origin isolation also does not authenticate a remote resource. A response satisfying CORS or CORP policy is eligible under that browser check; its business identity, integrity, and authorization properties still depend on separate mechanisms.
Capability gating is a consequence of the isolation boundary
Browsers gate certain high-resolution or shared-memory capabilities behind cross-origin isolation because those capabilities increase the importance of process and data separation. SharedArrayBuffer is the prominent example in web platform architecture.
The relevant application signal is crossOriginIsolated. A true value indicates that the environment has the cross-origin isolated capability under the browser’s processing model. It should not be inferred merely by inspecting one response header in application code.
The HTML Standard distinguishes logical and concrete cross-origin isolation modes. Both represent groups configured with the required policy shape, but only a concrete mode grants the cross-origin isolated capability on platforms able to provide the required security properties. This makes an important boundary explicit: policy headers request and shape isolation, while the user agent determines whether the capability can actually be granted.
Popup compatibility can conflict with strict isolation
Applications often rely on an auxiliary window for authentication, payment, document editing, or another cross-origin workflow. Strict COOP can change the opener relationship those flows expect.
That is not evidence that COOP failed. It is the direct consequence of moving the new document into a different browsing context group. A design that depends on synchronous cross-window references has a compatibility requirement that may conflict with the desired isolation boundary.
Message-based integration can reduce dependence on direct object relationships, but it does not erase origin checks. postMessage still requires careful target-origin selection and receiver-side validation. Cross-origin isolation changes the browser topology; it does not validate application messages on behalf of either endpoint.
Report-only policy can help expose group switches that enforcement would cause before a deployment commits to them. Reporting remains observational. It does not supply the protection of an enforced policy.
Resource policy becomes part of deployment architecture
The practical boundary created by COOP and COEP extends beyond the HTML document that emits the headers. A strict COEP deployment can fail because one required cross-origin response lacks compatible CORS or CORP behavior. A strict COOP deployment can disrupt a popup workflow because the application depended on an opener relationship that the new browsing context group no longer preserves.
That makes cross-origin isolation an architectural property rather than a pair of decorative security headers. The top-level document, popup topology, worker graph, fetch modes, and response policy of external resource origins all contribute to whether the isolated environment remains functional.
The security effect is correspondingly specific. COOP controls document grouping at top-level navigation boundaries; COEP constrains cross-origin embedding; their compatible combination can establish the browser state required for cross-origin isolated capabilities. Neither header replaces authorization, content integrity, CSP, or application-level origin validation. The boundary is valuable precisely because its scope is defined rather than universal.