cross-origin-opener-policy 实测 27 个首页：只有 3 个在发，没有一个用那个真能隔离的取值

实测 · 2026-09-04 · 27 个首页 · 每站一次请求 · 跨源隔离相关的响应头

样本 / 口径：2026-09-04 当天对 30 个首页各发一次 GET，桌面 Chrome UA，跟随跳转，不执行 JavaScript，出口在日本大阪。stackoverflow.com、medium.com、www.reddit.com 三个站返回 403，剔除后纳入 27 个。

27 个首页里只有 3 个在发 cross-origin-opener-policy：www.cloudflare.com、slack.com、stripe.com。三个里没有一个用 same-origin —— 那是真正能做到跨源隔离的取值；而 Cross-Origin-Embedder-Policy 在这 27 个站上出现 0 次。三个里还有一个发的就是浏览器本来的默认值。

怎么测的

每个站一次 GET，用桌面 Chrome UA 而不是 Googlebot，跟随跳转，全部响应头小写后记录。我们只找五个名字：Cross-Origin-Opener-Policy、Cross-Origin-Embedder-Policy、Cross-Origin-Resource-Policy，以及前两个的 -Report-Only 变体。下面所有数字都是站数，不是头的条数。

# 在你自己的页面上读同样几处
curl -sIL -A 'Mozilla/5.0' https://example.com/ \
  | grep -iE '^cross-origin-(opener|embedder|resource)-policy'

# 什么都不打印就是一个都没发，这在本面板里是多数情况

先说两条局限。这只是首页的一次读数，一个站完全可能把这些头设在 app 子域名上，而那个域名不在这个面板里 —— 27 个站里有 24 个发了 HSTS，说明它们不是那种不发响应头的站。另外，一次响应看不出「没发」是一个决定还是一次遗漏，再抓多少次也看不出来。

中文读者多半是撞见控制台那句提示才来搜的

同一天我们实跑了一次 Google 中文下拉（hl=zh-CN），这个词返回 10 条，其中两条是浏览器控制台里的整句：cross-origin-opener-policy policy would block the window.closed call 和 ...window.postmessage call。这不是噪音，是中文读者到达这个词的路径 —— 页面上撞见一句英文提示，整句复制去搜。

那句话里的 would block 是虚拟语气，字面意思是「本来会挡住」，而不是「已经挡住了」。我们没有在浏览器里复现这条提示，所以只按字面读到这里，不去解释 Chrome 具体在什么条件下打印它。真正要理解的是它在说哪件事：这个头管的是你打开的那扇新窗口，还连不连着原来那一扇。MDN 的定义句是「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，2026-09-04 访问）。连接被切断之后，脚本再去读 window.closed 或调 postMessage，对面已经不是原来那个对象了。

发了 cross-origin-opener-policy 的三个站，各发的是什么

三个站，三种情况。两个用了同一个取值，第三个用的是浏览器默认；三个里只有一个还额外发了报告模式的那一份。

选 same-origin-allow-popups 的两个站，产品里都有会弹窗的登录或支付流程。MDN 说这个取值的行为像 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」—— 那正好就是一次 OAuth 授权或收银台弹窗的形状。这个面板上的规律就是这么直接：发这个头的，都是产品本身会开窗口的站。

有一个站发的是默认值

www.cloudflare.com 发的是 unsafe-none。MDN 在这个取值条目的末尾写了一句：「This is the default value.」发它，浏览器的行为和不发一模一样。

这么做有说得通的理由 —— 把取值钉死，免得上游平台哪天改了自己的默认；或者覆盖掉某个平台替你设的值。从外面看不出是哪一种，我们也没有去问。能说的只有一句：这个面板上全部三条 cross-origin-opener-policy 里，有一条是在重述浏览器默认。

重述默认值的响应头是一份说明，不是一条策略。

stripe.com 那一处更奇怪。它同时发了强制头和 Cross-Origin-Opener-Policy-Report-Only，两个取值一字不差，都是 same-origin-allow-popups; report-to="wsp_coop"。报告模式的用处是在真正强制之前先看看影响，而这里被拿去「先看看」的那条策略，已经在强制生效了。它也是整个面板上唯一一个发 Reporting-Endpoints 的站，所以那些报告至少有地方可去。

这 27 个站没有一个做到了跨源隔离

跨源隔离要两个头同时到位，MDN 把这一对写明了：「you will need to set the COOP header to same-origin and the Cross-Origin-Embedder-Policy header to require-corp (or credentialless)」。2026-09-04 这一天，在这 27 个首页上，same-origin 出现 0 次，Cross-Origin-Embedder-Policy 出现 0 次。两个条件同时成立的站数因此是 0 —— 而且只要缺任何一个，结果都会是 0。

这一族的第三个头只有一个站在发：www.cloudflare.com 发了 Cross-Origin-Resource-Policy: cross-origin，那说的是「这份文档允许被别人怎么嵌」，不是隔离。

把它放回同一批响应里的其他安全头旁边，顺序本身就是结论。下面这张表是同一天、同一次抓取、同样 27 个响应。

采用率大体按这些头出现的先后往下掉，只有一处断层：permissions-policy 实测 27 个首页 和这一族一起被甩在下面，而它们的共同点是 —— 你得先了解自己的页面，才敢给出一个安全的取值。

这对你意味着什么

这不是抓取相关的响应头，这份数据里也没有任何排名信息。它不改变你的页面被怎么抓、怎么收录。它要紧在另外两件事上：你打开的那扇窗还能不能反过来碰到你，以及某一个特定取值是一组浏览器能力的门票。

1. 产品里有登录或支付弹窗的，看一眼这里两个站的选择。same-origin-allow-popups 是那个既留住弹窗、又切掉一般情况的取值。
2. 想用 SharedArrayBuffer 或者不被限流的高精度计时，两个头都要发，而第二个会把页面上所有第三方资源挡住，直到每一个都单独放行。这个面板上零个站付过这笔成本。
3. 今天什么都不发的，你就在 unsafe-none 上，和这 27 个里的 24 个一样。那是一个位置，不是一次疏忽，而且是网上多数站所在的位置。

同一批响应里另外两个头，量在 x-frame-options 实测 27 个首页 和 strict-transport-security 实测 27 个首页。想看自己的页面到底返回了哪些响应头，可以 看看 QueryWin 是怎么读一个页面的。

常见问题

你们是怎么测的

2026-09-04 当天，30 个首页各发一次 GET，桌面 Chrome UA，跟随跳转，全部响应头小写后记录。数的是站数不是头条数。出口在日本大阪，30 个里有 3 个返回 403 被剔除。

控制台里那句 policy would block 是出错了吗

那句话用的是虚拟语气，字面说的是「本来会挡住」。我们没有在浏览器里复现它，所以不解释 Chrome 具体什么时候打印这一句；能确定的只有它属于哪一族头，以及这一族头在管什么。

3 / 27 算低吗

放在同一批响应的其他安全头里看，是低的 —— 我们数的八个头里它排倒数第二。但换个角度就不好说了，因为多数站根本没有一扇需要被切断的窗口。

它影响 SEO 吗

这里没有任何证据说影响。这份测量完全不含排名数据。这个头作用在浏览器的浏览上下文组上，而一个只抓 HTML 的爬虫根本进不到那一层。

要做到跨源隔离得付出什么

两个头都要发、都要用严格取值，还要页面上每一个跨源资源都单独放行。这 27 个首页里零个做到了，这就是这次测量里关于成本最清楚的一个信号。