COOP, COEP and CORP: separate windows and resources deliberately

Which additional boundary do you need?

An origin comprises scheme, host and port. Different subdomains therefore have different origins. The same-origin policy already restricts certain forms of access between them. Additional mechanisms can separate window relationships or prevent certain external responses from entering a document context. Side-channel attacks such as Spectre are one motivation; the headers do not eliminate the underlying class of all side channels.

This does not create a blanket requirement to enable cross-origin isolation on an ordinary information page. For an application that needs shared memory, however, this browser state may be a specific prerequisite. Unsupported clients and working alternatives then belong in the product decision. HTML: cross-origin policies

The Web Security Check reads the headers of the final response after redirects. It can infer a configuration from suitable values. It does not run a browser or measure crossOriginIsolated, your popups' relationships or the compatibility of every resource loaded subsequently.

Three tasks, not interchangeable headers

COOP: determine the window relationship

same-origin severs the relationship with a different popup when the origins and participating policies do not match. same-origin-allow-popups permits certain popups opened by the document itself with unsafe-none, but does not replace same-origin in the usual COOP/COEP path to isolation. unsafe-none is the default and does not itself require additional separation; the other document's policy may still cause separation.

The HTML Standard also defines noopener-allow-popups. This severs the opener relationship, but does not create a comprehensive security boundary between applications on the same origin: shared storage and other access paths still need consideration. This less common variant and its browser support belong in a targeted architecture review, not a universal header bundle. HTML § 7.1.3

COEP: consider request mode and response together

With require-corp, cross-origin resources requested in no-cors mode need a matching CORP permission. If the element instead loads in CORS mode, CORS access must succeed. An Access-Control-Allow-Origin header on the server alone does not change the mode of an ordinary <img> request.

credentialless permits cross-origin no-cors resources without explicit CORP permission by omitting credentials for those requests. It does not disable an explicitly restrictive CORP policy. CORS requests remain subject to CORS. Personalised resources may look different or fail without their credentials; frames have additional conditions.

This value is not available everywhere: the compatibility data read on 27 September 2026 list credentialless for Chromium and desktop Firefox, but not Safari or Firefox for Android. This is documented implementation status, not our own device acceptance test. unsafe-none imposes no additional COEP restriction. HTML § 7.1.4

CORP: serve the resource for its intended use

same-origin restricts the covered use to the same origin. Under the Fetch rules, same-site permits a broader domain relationship, but does not equate to a trusted organisation. A subdomain managed by someone else may be included. The algorithm also has a transport condition: a resource served over HTTPS is not made available to an HTTP initiator merely because their domains have the same relationship. cross-origin permits the covered use by other origins; this can be precisely the right setting for a public CDN.

CORP does not grant CORS read permission. Nor does it prevent another HTTP client from fetching a publicly reachable file. A blocked image request therefore does not establish a complete hotlinking or access restriction. Fetch § 3.7

An image under require-corp: two permitted paths

The local Chromium check conducted for the source review confirmed these contrasting cases. This image table is insufficient for frames: under COEP, the embedded documents must also meet the relevant embedder policy conditions. A CORP header on an iframe target alone is therefore not a universal fix.

A starting point for the usual COOP/COEP path to cross-origin isolation is:

Cross-Origin-Opener-Policy: same-origin
Cross-Origin-Embedder-Policy: require-corp

This also requires a secure context, a supporting browser and the remaining policy conditions, in particular no denial through the cross-origin-isolated Permissions Policy. CORP is not a mandatory third document header. Check in the relevant document:

console.log({ secure: window.isSecureContext, isolated: window.crossOriginIsolated });

The value describes this context. It confirms neither every embedded page, the operating system's actual process allocation nor tested protection against Spectre. Newer alternative mechanisms are covered under additional headers.

Introduce policies around actual user journeys

1. Decide whether you need window separation, resource restrictions or cross-origin isolation. Inventory third-party images, fonts, scripts, frames, workers and popups.
2. Identify the operator responsible for each response. CORP permission must come from the resource server; a header only on your own homepage cannot fix another server's response.
3. Try the intended rules in an isolated environment. COOP/COEP Report-Only can indicate conflicts if reporting is actually configured and supported. An absence of reports does not establish compatibility; see the Reporting API.
4. Check positive and negative cases: intended images and frames, sign-in, payment, popup communication and the required API. Inspect console errors, the request modes used and the actual isolation state.
5. Roll out to a limited scope. Keep the previous header configuration, matching application version and cache handling ready for rollback. After rollback, documents must be reloaded and window relationships re-established.

There is no universally low-risk sequence of ‘COOP first, then CORP, then COEP’. COOP alone can break a login popup flow, and CORP can block an intended image. Repeated COEP values such as require-corp, require-corp do not strengthen the policy: the structured field becomes invalid and falls back to the default under the standard. Correct the responsible delivery architecture.

Distinguish CORS, permissions and compliance

CORS governs whether browser code may read a particular cross-origin response. The mechanisms described here serve other purposes. None replaces authentication, server-side authorisation, CSP or checking the trustworthiness of a permitted script. For API-specific questions, continue with the API security guide.

Such a configuration does not establish general compliance with NIS2 or PCI requirements. A permitted but compromised script can still act within the document; the headers neither inventory nor authorise payment scripts. The header check also does not measure actual process isolation. Compliance overview