Cross-Origin-Opener-Policy on 27 homepages: three send it, and none of them picks the value that isolates anything

FIELD TEST · 2026-09-04 · 27 homepages · one request each · cross-origin isolation headers

Sample and method: 30 homepages fetched once each on 2026-09-04 with a desktop Chrome user agent, redirects followed, no JavaScript executed, exit node in Osaka, Japan. Three dropped out — stackoverflow.com, medium.com and www.reddit.com each returned 403 — leaving 27.

Three of the 27 homepages send a Cross-Origin-Opener-Policy header: www.cloudflare.com, slack.com and stripe.com. None of the three sends same-origin, the value that isolation actually requires, and zero of the 27 send a Cross-Origin-Embedder-Policy at all. One of the three sends the browser's own default as an explicit instruction.

How we measured it

One GET per site, desktop Chrome user agent rather than Googlebot, redirects followed, every response header recorded lowercased. We looked for five names: Cross-Origin-Opener-Policy, Cross-Origin-Embedder-Policy, Cross-Origin-Resource-Policy, and the -Report-Only variants of the first two. Counts below are sites, not header instances.

# The same reading on one of your own pages
curl -sIL -A 'Mozilla/5.0' https://example.com/ \
  | grep -iE '^cross-origin-(opener|embedder|resource)-policy'

# Nothing printed means nothing is sent, which is the majority case here

Two limits worth stating before the numbers. This is a homepage-only reading, and a site may set these headers on an app subdomain that never appears in this panel — 24 of the 27 send HSTS, so these are not sites that ignore headers in general. We also cannot tell from one response whether a missing header is a decision or an omission, and no amount of fetching would tell us that.

Who sends Cross-Origin-Opener-Policy, and with what value

Three sites, three different situations. The header controls whether a window you open stays connected to yours: it "allows a website to control whether a new top-level document, opened using Window.open() or by navigating to a new page, is opened in the same browsing context group (BCG) or in a new browsing context group" (Cross-Origin-Opener-Policy, MDN, read 2026-09-04).

The two sites choosing same-origin-allow-popups both run authentication and payment flows that open windows. MDN describes that value as behaving like same-origin "except that it allows the opening of documents using Window.open() in the same BCG if they have a COOP value of unsafe-none" — which is exactly the shape of an OAuth or checkout popup. That is the pattern here: the sites that send this header are the sites whose product opens windows.

One site sends the default on purpose

www.cloudflare.com sends unsafe-none. MDN's line on that value ends with four words that make the choice interesting: "This is the default value." Sending it changes nothing a browser would not already have done.

There are reasonable reasons to do that — pinning a value so an upstream default cannot change it later, or overriding something a platform sets. We cannot tell which from outside, and we did not ask. What we can say is that on this panel, one third of all Cross-Origin-Opener-Policy headers restate the browser default.

A header that repeats the default is documentation, not a policy.

stripe.com has the other oddity. It sends both the enforcing header and Cross-Origin-Opener-Policy-Report-Only, and the two carry the identical value, same-origin-allow-popups; report-to="wsp_coop". Report-only exists to test a policy before enforcing it; here the policy being tested is already the one in force. It is also the only site on the panel sending a Reporting-Endpoints header, so the reports do have somewhere to go.

Nobody here is cross-origin isolated

Cross-origin isolation needs two headers together, and MDN states the pair: "you will need to set the COOP header to same-origin and the Cross-Origin-Embedder-Policy header to require-corp (or credentialless)". On 2026-09-04, across these 27 homepages, same-origin appears zero times and Cross-Origin-Embedder-Policy appears zero times. The count of homepages meeting both conditions is therefore zero, and it would have been zero even if only one of the two had been missing.

Only one site sends the third member of the family: www.cloudflare.com sends Cross-Origin-Resource-Policy: cross-origin, which is a statement about how this document may be embedded elsewhere rather than about isolation.

Put next to the rest of the security headers on the same 27 responses, the ordering is the point. These are the same responses, the same day, the same fetch.

Adoption falls off in the order the headers arrived, with one break in the pattern: Permissions-Policy across 27 homepages and this family sit far below the rest, and both are the ones that require you to know something about your own page before you can set a value safely.

What this means for your site

This is not a crawling header and this data set contains no ranking information. Nothing here changes how your pages are fetched or indexed. It matters for two other reasons: it decides whether a window you open can still reach back into yours, and one specific value is the entry ticket for a set of browser features.

1. If your product opens a popup for login or payment, look at what the two sites doing that here chose. same-origin-allow-popups is the value that keeps the popup working while cutting the general case.
2. If you want SharedArrayBuffer or unthrottled timers, you need both headers, and the second one will break embedded third-party resources until each of them opts in. Zero sites on this panel have paid that cost.
3. If you send nothing today, you are on unsafe-none, which is where 24 of these 27 sites are. That is a position, not an oversight, and it is the one most of the web is in.

Two neighbouring headers on the same responses are measured in X-Frame-Options across 27 homepages and HSTS across 27 homepages. To read the headers your own pages return before any of this is a decision, see how QueryWin reads a page.

Common questions

How did you measure this?

One GET per homepage on 2026-09-04, desktop Chrome user agent, redirects followed, all response headers recorded and lowercased. Site counts, not header counts. Exit node in Osaka, Japan. Three of the 30 attempted returned 403 and were excluded.

Is 3 out of 27 low?

Against the other security headers on the same responses, yes — it sits second from the bottom of the eight we counted. Against what the header is for, the number is harder to read, because most sites never open a window they need to sever.

Does Cross-Origin-Opener-Policy affect SEO?

Nothing here shows that it does. The measurement contains no ranking data. The header acts on browsing context groups in a browser, which is a layer a crawler fetching HTML never enters.

Why is unsafe-none worth sending if it is the default?

We do not know why these particular teams did it. Pinning a value against a platform that might change its own default is one plausible reason. We did not contact anyone and we are not going to guess further than that.

What would it take to be cross-origin isolated?

Both headers, at the strict values, plus every cross-origin resource on the page opting in. Zero of the 27 homepages here do it, which is the clearest signal in this measurement about what that costs.