Three headers, three jobs, three layers
The similarity of the names is the real reason behind most misconfigurations. Cross-Origin-Opener-Policy acts on the window group: it decides whether a document stays connected to the window that opened it. Cross-Origin-Embedder-Policy acts on the document and everything it loads afterwards: it demands explicit clearance for every subresource. Cross-Origin-Resource-Policy acts on the individual response and is set by the serving side: it states who may embed this resource. A classification of the common security headers is in the article on HTTP security headers.
There is a technical reason why the three are named together: two of them interlock. A document counts as cross-origin isolated only once it sets COOP to same-origin and additionally COEP to require-corp or credentialless (MDN Web Docs). Only that state releases interfaces the browser otherwise keeps locked. CORP is the counterpart: without clearance from the serving resource, a document running require-corp does not reach third-party material. The full protective effect appears in the interplay - and that is where configurations drift apart.
- Cross-Origin-Opener-Policy (COOP): valid values are unsafe-none, same-origin-allow-popups, same-origin and the newer noopener-allow-popups.
- Cross-Origin-Embedder-Policy (COEP): valid values are unsafe-none, require-corp and credentialless.
- Cross-Origin-Resource-Policy (CORP): valid values are same-origin, same-site and cross-origin.
- COOP and COEP are set by the document, CORP by every single response - image, font file, script, embedded frame.
- Invalid values fall back silently: the browser reports no error, it takes the default and keeps loading.
- What counts is the response header, not the HTML: a meta element replaces none of the three headers.
How closely the three sit together shows in the error distribution: 5.6 percent of all observed COEP headers carry a value the browser does not recognise in that position (Web Almanac 2025). Over 4 percent of those are same-origin - valid, but for CORP or COOP, not for COEP (Web Almanac 2025). The browser discards the entry and carries on as if it were not there. Nothing of this shows on the page; it becomes visible only when someone reads out the response header and checks the value against the permitted list.
COOP: the cut through the window group
A window that opens another keeps a connection to it: window.opener. Through that connection properties can be read and, in some constellations, side effects triggered. COOP cuts the connection. same-origin keeps only what shares the origin; everything else lands in a window group of its own and sees null. same-origin-allow-popups is the milder step: the document separates from its opener but keeps the windows it opens itself. unsafe-none matches the default and changes nothing.
Those who do set COOP now mostly choose the strictest step: the share of same-origin among all COOP headers rose within a year from 47.5 to 61.6 percent (Web Almanac 2025). The newer value noopener-allow-popups, which separates the window group without losing the pop-ups it opens, sits at 0.03 percent by contrast (Web Almanac 2025) - it has not yet arrived in the field. For operators that means two things: the strict step has become the normal case among adopters, and the gentler intermediate steps are so rarely deployed that there is little practical experience with them.
Sign-in windows, payment dialogues and approval steps that open a pop-up and report their result back via window.opener break under COOP same-origin without a conspicuous error message. The flow looks familiar right up to the last step and then ends in a window that can no longer close itself. Before switching to enforcement, every flow that opens a second window belongs on a list - together with the intermediate step same-origin-allow-popups. How such flows can be replayed automatically is shown in the article on monitoring sign-in and checkout.
COEP: the load barrier for subresources
COEP reverses the burden of proof. Without the header a document loads third-party images, fonts and scripts without asking; with require-corp every subresource must bring clearance - a CORP header or a successful CORS response. Without either, the browser blocks the resource. credentialless is the gentler route: the resource is loaded, but without credentials, meaning without cookies and without client certificates. The role the cookie attributes play in this is covered in the article on secure session cookies.
| Header | Who sets it | What it does | Adoption 2025 (mobile) |
|---|---|---|---|
| Cross-Origin-Opener-Policy | the document itself | separates the document from the opener's window group | over 2 percent of websites |
| Cross-Origin-Embedder-Policy | the document itself | requires clearance for every subresource | nearly 0.75 percent of websites |
| Cross-Origin-Resource-Policy | the served resource | allows or refuses embedding by foreign documents | over 2 percent of websites |
| Document Policy | the document itself | reports and limits individual document features | 0.10 percent of pages |
The distribution of the values that are set shows how cautiously the header is used. Over 86 percent of all COEP headers on mobile requests carry unsafe-none and thereby switch the effect back off (Web Almanac 2025). require-corp reaches 4.92 percent, credentialless 1.89 percent (Web Almanac 2025). So those who set the header mostly set it in a way that does nothing: as a placeholder, as a leftover from a template, or as a prepared switch nobody has flipped yet.
CORP: the answer from the other side
CORP is the only one of the three that is set not by the embedding document but by the served resource itself. same-origin releases it for its own origin, same-site for its own site including subdomains, cross-origin for any document. It is protection and clearance at once: it keeps foreign pages from embedding your images and scripts, and it is the precondition for your own resources to arrive in a document running require-corp.
In practice CORP is used predominantly as clearance: 80.5 percent of the observed CORP headers on mobile requests carry cross-origin (Web Almanac 2025). That share has dropped by more than ten percentage points against the previous year, while same-origin has risen to 15.63 percent (Web Almanac 2025). The movement is towards locking down: more providers are restricting their resources to their own origin. For those doing the embedding this means an embed that worked without further ado yesterday may today require a clearance that no longer exists at that address - a state that only becomes apparent through repeated measurement.
- CORP does not replace CORS: it governs embedding, not read access by script. The distinction and the frequent misconfigurations are in the article on CORS configuration errors.
- CORP does not protect content from direct retrieval: calling the address in a browser remains possible.
- CORP acts per response: one path can be cleared while the one next to it is not - and the cache in front remembers both states.
- CORP without COEP on the other side has no effect: a document without require-corp does not ask for the clearance.
- CORP in the HTML has no effect: the value is read from the response header, not from an element in the head section.
For your own delivery this yields a simple order of operations. First separate what should be publicly embeddable from what should not: logos, fonts and open image files get cross-origin, anything tied to a session gets same-origin. Then check whether an upstream delivery layer carries the header through - under require-corp a file without a CORP header behaves like a blocked one. Why caches keep handing out stale responses after a release is described in the article on cache traps after deployment.
CORP is a property of the response, not of the document embedding it. Checking the header on the home page is therefore not enough: it belongs on every file that foreign documents are meant to embed - and it is missing most often exactly where delivery runs over a different path than the HTML.
What cross-origin isolation gives back
The effort has a purpose. A document that sets COOP to same-origin and COEP to require-corp or credentialless reaches the crossOriginIsolated state (MDN Web Docs). In that state the browser releases interfaces it otherwise keeps locked: memory shared between the main thread and worker threads, measurement of the page's own memory use, and the full resolution of timing measurement. For compute-heavy applications in the browser - image editing, map computation, simulation - that is the difference between usable and unusable. For an ordinary content page it is a state with no recognisable return.
The difference is clearest in timing. In an isolated context performance.now() delivers a resolution of 5 microseconds (MDN Web Docs); outside it the figure is 100 microseconds (MDN Web Docs). The factor of 20 is not thrift, it is defence: fine-grained timing is the lever for side-channel attacks of the Spectre family. Anyone able to measure runtime differences precisely enough reads memory contents of foreign origin that sit in the same process. The browser therefore coarsens the clock for every document that has not sealed off its environment, and hands it back only once that sealing has been demonstrated.
How rarely that state is actually reached shows in measurements on real page loads. The Chrome counter for documents with COOP and COEP isolation stands at a share of 0.00136697 of all page loads, roughly 0.14 percent (Chrome Platform Status 2026). The newer mechanism Document Isolation Policy, meant to reach isolation without cutting through the window group, already sits above it at 0.00656973 (Chrome Platform Status 2026). Cross-origin isolation is therefore not a baseline state of the web but a deliberate decision for individual applications - and the figures suggest the route towards it is currently being rebuilt.
The values that get confused
Each of the three headers has its own list of values, and the lists overlap only partly. same-origin is valid for COOP and CORP, cross-origin only for CORP, require-corp and credentialless only for COEP, unsafe-none for COOP and COEP. A value from the wrong list produces no warning: the browser discards the header line and falls back to the default. That is why the value actually served belongs read out and checked, not assumed.
The most frequent error: over 4 percent of all COEP headers carry this value (Web Almanac 2025). It is valid - but for COOP and CORP. COEP does not know it and carries on with unsafe-none.
None of the three headers is read from the HTML. An entry in the head section has no effect, and a look at the source code falsely confirms that it is set.
The origin server sets CORP, the upstream delivery does not pass it on. Measurement happens at the origin, loading through the cache - and there the clearance is missing.
A Report-Only header without a configured endpoint produces no reports. The preliminary stage runs empty, and the empty result is read as clearance for enforcement.
The route through the reporting mode
Both document headers have a reporting variant: Cross-Origin-Opener-Policy-Report-Only and Cross-Origin-Embedder-Policy-Report-Only. They leave the behaviour untouched and report what enforcement would have done. Together with a Reporting-Endpoints header naming a target, they produce a list of the places that would break, before they break - for COEP the resources without clearance, for COOP the window relationships that would be severed.
Two things decide the worth of that preliminary stage. The running time: a week covers the weekly rhythm, a month also covers billing runs, campaign launches and seasonal embeds. And the coverage: reports arise only on pages that are actually called. An area without traffic delivers no reports and looks unremarkable although nothing was checked there - an empty result and a failed measurement procedure look identical from the outside.
The share of this value remains above 86 percent on mobile requests but has fallen by almost 2 percent against the previous year, which may indicate that developers are beginning to change how they handle the header.
— Web Almanac 2025, Security chapter, paraphrased
What breaks when embedding third-party content
The step to require-corp is not an entry in a configuration but an intervention in the load list. Everything of foreign origin is affected: map sections, video embeds, font files, payment windows, counting pixels, profile images from a foreign store. After the switch each of those resources needs a CORP clearance or a valid CORS response. Where the clearance cannot be set by hand, three options remain: credentialless, an own intermediate delivery, or doing without the embed.
The scale of that intervention can be quantified. At least 90 percent of all pages embed at least one third party (Web Almanac 2025), and the median sits at 83 requests to foreign servers on desktop and 79 on mobile devices (Web Almanac 2025). In embedded frames alone, 33.3 million were counted in the mobile crawl (Web Almanac 2025). Every single one of those requests is a potential blocking case under require-corp. What further risks foreign scripts carry is described in the article on third-party scripts; securing individual embedded files is covered in the article on Subresource Integrity.
# Stage 1: observe - collect reports, block nothing
add_header Reporting-Endpoints 'iso="https://example.test/reports/iso"' always;
add_header Cross-Origin-Opener-Policy-Report-Only 'same-origin; report-to="iso"' always;
add_header Cross-Origin-Embedder-Policy-Report-Only 'require-corp; report-to="iso"' always;
# Stage 2: enforce, only once the reports stay empty
# add_header Cross-Origin-Opener-Policy 'same-origin' always;
# add_header Cross-Origin-Embedder-Policy 'require-corp' always;
# Serve your own images and fonts to foreign documents
location /assets/ {
add_header Cross-Origin-Resource-Policy 'cross-origin' always;
}
# Anything tied to a session stays on its own origin
location /account/ {
add_header Cross-Origin-Resource-Policy 'same-origin' always;
}How widespread the three headers really are
The growth is steady, but it starts from a very small base. COOP was found on 0.23 percent of requests in 2022, on 0.68 percent in 2023 and on 1.07 percent in 2024 (Web Almanac 2024) - roughly a doubling each year. In 2025 CORP and COOP passed the two percent mark for the first time (Web Almanac 2025), COEP sits at nearly 0.75 percent (Web Almanac 2025). The survey behind these shares covers 16,213,084 websites from the July 2025 crawl (Web Almanac 2025).
- Transport encryption is practically finished: over 98.8 percent of all requests on mobile connections run over HTTPS (Web Almanac 2025).
- Strongest riser among the security headers: Strict-Transport-Security, up 4.02 percentage points against the previous year (Web Almanac 2025).
- The older tool grows faster: the sandbox attribute on embedded frames rose from 20.0 to 22.7 percent (Web Almanac 2025).
- Newer mechanisms stay small: Document Policy reaches 0.10 percent of the pages crawled (Web Almanac 2025).
- Within the adopters the trend is towards strictness: the COOP value same-origin rose from 47.5 to 61.6 percent of COOP headers (Web Almanac 2025).
Two conclusions follow from these figures. First: the cross-origin headers are not baseline protection picked up in passing but a decision with consequences for every embed of foreign content - which is why they sit orders of magnitude below the values for transport encryption. Second: within the group that does set them, the movement is towards the stricter values. Anyone planning today therefore plans for the strict step and for the route towards it, not for the intermediate state. Which components in your own stack are due for replacement anyway is shown in the article on components without maintenance support.
Observing the headers in production
A response header is a transient state. It arises in the application, in the web server, in an upstream cache or in a delivery layer, and each of those places can add it, overwrite it or remove it. A check at the moment of setup therefore says little about the state three months later. Four things belong under observation: presence, exact value, identical setting across HTML, image, font and interface response, and the clearance of the embedded resources.
In practice that means a list of addresses, a fixed cadence, a stored target value per header and an alert on deviation. The security scan reads out the response headers and compares them against the stored state; for a single look at one address the security score is enough. For flows that open a second window, browser monitoring extends the header check with the actual flow. How a check endpoint reports the state behind the surface is described in the article on the health check endpoint; that a browser retrieval differs from one by an application is shown in the article on the incomplete certificate chain.
The adoption figures come from the security chapter of the Web Almanac 2025, which rests on the HTTP Archive crawl of July 2025 covering 16,213,084 websites (Web Almanac 2025). The growth series for COOP from 2022 to 2024 comes from the previous year's edition (Web Almanac 2024). The prerequisites for the isolated state and the two timing resolution figures are documented in the MDN Web Docs (MDN Web Docs). The shares of actual isolation across real page loads come from the browser's public usage counters (Chrome Platform Status 2026). All figures were re-read at their source on 12 September 2026; the quotes are stored with the article.