最近浏览器升级遇到了好几次由于新版跨域导致的各种问题。复习下相关知识。

什么是跨域

广义的跨域

1.) 资源跳转： A链接、重定向、表单提交
2.) 资源嵌入： <link>、<script>、<img>、<frame>等dom标签，还有样式中background:url()、@font-face()等文件外链
3.) 脚本请求： js发起的ajax请求、dom和js对象的跨域操作等

常说的跨域

览器同源策略限制的一类请求场景。

同源策略/SOP（Same origin policy）是一种约定，由Netscape公司1995年引入浏览器，它是浏览器最核心也最基本的安全功能，如果缺少了同源策略，浏览器很容易受到XSS、CSFR等攻击。所谓同源是指"协议+域名+端口"三者相同，即便两个不同的域名指向同一个ip地址，也非同源。

同源策略限制以下几种行为：

1.) Cookie、LocalStorage 和 IndexDB 无法读取
2.) DOM 和 Js对象无法获得
3.) AJAX 请求不能发送

常见跨域场景

URL                                      说明                    是否允许通信
http://www.domain.com/a.js
http://www.domain.com/b.js         同一域名，不同文件或路径           允许
http://www.domain.com/lab/c.js

http://www.domain.com:8000/a.js
http://www.domain.com/b.js         同一域名，不同端口                不允许
 
http://www.domain.com/a.js
https://www.domain.com/b.js        同一域名，不同协议                不允许
 
http://www.domain.com/a.js
http://192.168.4.12/b.js           域名和域名对应相同ip              不允许
 
http://www.domain.com/a.js
http://x.domain.com/b.js           主域相同，子域不同                 不允许
http://domain.com/c.js
 
http://www.domain1.com/a.js
http://www.domain2.com/b.js        不同域名                         不允许

跨域解决方案

1、通过jsonp跨域

2、 document.domain + iframe跨域

3、 location.hash + iframe

4、 window.name + iframe跨域

5、 postMessage跨域

6、跨域资源共享（CORS）

7、 nginx代理跨域

8、 nodejs中间件代理跨域

9、 WebSocket协议跨域

以上是之前常用的一些方式，后来浏览器开始了版本大爆发。这些知识有点跟不上了。Chrome 83 开发者工具支持了 COEP 和 COOP 的 debug，Firefox 74 支持了 CORP，加上之前熟悉的 CORS 和不熟悉的 CORB。CO* 家族繁荣壮大了。

熟悉又陌生的CO*家族

CORS（Cross-origin resource sharing）

先从这个家族最熟悉的开始

CORS是一个W3C标准，全称是"跨域资源共享"（Cross-origin resource sharing）。

CORS需要浏览器和服务器同时支持。目前，所有浏览器都支持该功能，IE浏览器不能低于IE10。

浏览器将CORS请求分成两类：简单请求（simple request）和非简单请求（not-so-simple request）。

简单请求

简单请求为了兼容表单（form），因为历史上表单一直可以发出跨域请求。AJAX 的跨域设计就是，只要表单可以发，AJAX 就可以直接发。

（1) 请求方法是以下三种方法之一：

HEAD
GET
POST

（2）HTTP的头信息不超出以下几种字段：

Accept
Accept-Language
Content-Language
Last-Event-ID
Content-Type：只限于三个值application/x-www-form-urlencoded、multipart/form-data、text/plain

简单请求，浏览器直接发出CORS请求。具体来说，就是在头信息之中，增加一个Origin字段。用来说明，本次请求来自哪个源（协议 + 域名 + 端口）。服务器根据这个值，决定是否同意这次请求。

如果Origin指定的源，不在许可范围内，服务器会返回一个正常的HTTP回应。浏览器发现，这个回应的头信息没有包含Access-Control-Allow-Origin字段（详见下文），就知道出错了，从而抛出一个错误，被XMLHttpRequest的onerror回调函数捕获。注意，这种错误无法通过状态码识别，因为HTTP回应的状态码有可能是200。

如果Origin指定的域名在许可范围内，服务器返回的响应，会多出几个头信息字段。

Access-Control-Allow-Origin: http://api.alipay.com
Access-Control-Allow-Credentials: true
Access-Control-Expose-Headers: FooBar
Content-Type: text/html; charset=utf-8

上面的头信息之中，有三个与CORS请求相关的字段，都以Access-Control-开头。

（1）Access-Control-Allow-Origin

该字段是必须的。它的值要么是请求时Origin字段的值，要么是一个*，表示接受任意域名的请求。

（2）Access-Control-Allow-Credentials

该字段可选。它的值是一个布尔值，表示是否允许发送Cookie。默认情况下，Cookie不包括在CORS请求之中。设为true，即表示服务器明确许可，Cookie可以包含在请求中，一起发给服务器。这个值也只能设为true，如果服务器不要浏览器发送Cookie，删除该字段即可。

（3）Access-Control-Expose-Headers

该字段可选。CORS请求时，XMLHttpRequest对象的getResponseHeader()方法只能拿到6个基本字段：Cache-Control、Content-Language、Content-Type、Expires、Last-Modified、Pragma。如果想拿到其他字段，就必须在Access-Control-Expose-Headers里面指定。上面的例子指定，getResponseHeader('FooBar')可以返回FooBar字段的值。

非简单请求

预检请求

非简单请求是那种对服务器有特殊要求的请求，比如请求方法是PUT或DELETE，或者Content-Type字段的类型是application/json。

非简单请求的CORS请求，会在正式通信之前，增加一次HTTP查询请求，称为"预检"请求（preflight）。

浏览器先询问服务器，当前网页所在的域名是否在服务器的许可名单之中，以及可以使用哪些HTTP动词和头信息字段。只有得到肯定答复，浏览器才会发出正式的XMLHttpRequest请求，否则就报错。

var url = 'http://api.alipay.com/cors';
var xhr = new XMLHttpRequest();
xhr.open('PUT', url, true);
xhr.setRequestHeader('X-Custom-Header', 'value');
xhr.send();

上面代码中，HTTP请求的方法是PUT，并且发送一个自定义头信息X-Custom-Header。

浏览器发现，这是一个非简单请求，就自动发出一个"预检"请求，要求服务器确认可以这样请求。下面是这个"预检"请求的HTTP头信息。

OPTIONS /cors HTTP/1.1
Origin: http://api.alipay.com
Access-Control-Request-Method: PUT
Access-Control-Request-Headers: X-Custom-Header
Host: api.alice.com
Accept-Language: en-US
Connection: keep-alive
User-Agent: Mozilla/5.0...

"预检"请求用的请求方法是OPTIONS，表示这个请求是用来询问的。头信息里面，关键字段是Origin，表示请求来自哪个源。

除了Origin字段，"预检"请求的头信息包括两个特殊字段。

（1）Access-Control-Request-Method

该字段是必须的，用来列出浏览器的CORS请求会用到哪些HTTP方法，上例是PUT。

（2）Access-Control-Request-Headers

该字段是一个逗号分隔的字符串，指定浏览器CORS请求会额外发送的头信息字段，上例是X-Custom-Header。

预检请求的回应

服务器收到"预检"请求以后，检查了Origin、Access-Control-Request-Method和Access-Control-Request-Headers字段以后，确认允许跨源请求，就可以做出回应。

HTTP/1.1 200 OK
Date: Mon, 01 Dec 2020 01:15:39 GMT
Server: Apache/2.0.61 (Unix)
Access-Control-Allow-Origin: http://api.alipay.com
Access-Control-Allow-Methods: GET, POST, PUT
Access-Control-Allow-Headers: X-Custom-Header
Content-Type: text/html; charset=utf-8
Content-Encoding: gzip
Content-Length: 0
Keep-Alive: timeout=2, max=100
Connection: Keep-Alive
Content-Type: text/plain

上面的HTTP回应中，关键的是Access-Control-Allow-Origin字段，表示http://api.alipay.com可以请求数据。该字段也可以设为星号，表示同意任意跨源请求。

Access-Control-Allow-Origin: *

如果服务器否定了"预检"请求，会返回一个正常的HTTP回应，但是没有任何CORS相关的头信息字段。这时，浏览器就会认定，服务器不同意预检请求，因此触发一个错误，被XMLHttpRequest对象的onerror回调函数捕获。控制台会打印出如下的报错信息。

XMLHttpRequest cannot load http://api.alipay.com.
Origin http://api.bob.com is not allowed by Access-Control-Allow-Origin.

服务器回应的其他CORS相关字段如下。

Access-Control-Allow-Methods: GET, POST, PUT
Access-Control-Allow-Headers: X-Custom-Header
Access-Control-Allow-Credentials: true
Access-Control-Max-Age: 1728000

（1）Access-Control-Allow-Methods

该字段必需，它的值是逗号分隔的一个字符串，表明服务器支持的所有跨域请求的方法。注意，返回的是所有支持的方法，而不单是浏览器请求的那个方法。这是为了避免多次"预检"请求。

（2）Access-Control-Allow-Headers

如果浏览器请求包括Access-Control-Request-Headers字段，则Access-Control-Allow-Headers字段是必需的。它也是一个逗号分隔的字符串，表明服务器支持的所有头信息字段，不限于浏览器在"预检"中请求的字段。

（3）Access-Control-Allow-Credentials

该字段与简单请求时的含义相同。

（4）Access-Control-Max-Age

该字段可选，用来指定本次预检请求的有效期，单位为秒。上面结果中，有效期是20天（1728000秒），即允许缓存该条回应1728000秒（即20天），在此期间，不用发出另一条预检请求。

浏览器的正常请求和回应

一旦服务器通过了"预检"请求，以后每次浏览器正常的CORS请求，就都跟简单请求一样，会有一个Origin头信息字段。服务器的回应，也都会有一个Access-Control-Allow-Origin头信息字段。

下面是"预检"请求之后，浏览器的正常CORS请求。

PUT /cors HTTP/1.1
Origin: http://api.alipay.com
Host: api.alipay.com
X-Custom-Header: value
Accept-Language: en-US
Connection: keep-alive
User-Agent: Mozilla/5.0...

上面头信息的Origin字段是浏览器自动添加的。

下面是服务器正常的回应。

Access-Control-Allow-Origin: http://api.alipay.com
Content-Type: text/html; charset=utf-8

上面头信息中，Access-Control-Allow-Origin字段是每次回应都必定包含的。

withCredentials

上面说到，CORS请求默认不发送Cookie和HTTP认证信息。如果要把Cookie发到服务器，一方面要服务器同意，指定Access-Control-Allow-Credentials字段。

Access-Control-Allow-Credentials: true

另一方面，开发者必须在AJAX请求中打开withCredentials属性。

var xhr = new XMLHttpRequest();
xhr.withCredentials = true;

否则，即使服务器同意发送Cookie，浏览器也不会发送。或者，服务器要求设置Cookie，浏览器也不会处理。

但是，如果省略withCredentials设置，有的浏览器还是会一起发送Cookie。这时，可以显式关闭withCredentials。

xhr.withCredentials = false;

需要注意的是，如果要发送Cookie，Access-Control-Allow-Origin就不能设为星号，必须指定明确的、与请求网页一致的域名。同时，Cookie依然遵循同源政策，只有用服务器域名设置的Cookie才会上传，其他域名的Cookie并不会上传，且（跨源）原网页代码中的document.cookie也无法读取服务器域名下的Cookie。

CORB（Cross-Origin Read Blocking）

不知道大家在调试BUG的时候有没有在控制台看到这么一条警告

Cross-Origin Read Blocking (CORB) blocked cross-origin response https://www.chromium.org/ with MIME type text/html. See https://www.chromestatus.com/... for more details.

印象中这个警告有好久了。一直没管。这次也查了下

先看下给的文档

an algorithm by which dubious cross-origin resource loads may be identified and blocked by web browsers before they reach the web page.

浏览器在加载可以跨域资源时，在资源载入页面之前，对其进行识别和拦截的算法。

前置知识

进入正题之前先学习下一般不怎么接触的姿势。

https://www.bilibili.com/video/av18144159/

旁路攻击（side-channel attacks）

首先需要了解的是旁路攻击这个术语，关于术语本身的解释，可以去维基百科搜索。简单讲的话，就是从软件系统的物理实现层获取信息进行攻击的手段，软件系统在正常运行时，产生了一些边缘特征，这些特征可以体现一些隐私信息。

这么说可能略显抽象，就拿后文视频链接中列举的例子说明一下，假设小 A 的账户密码是 gyease，小 B 想破解小 A 的密码，他可以这么做：

首先他可以先输入 aaaaaa，之后记录一下从点击登录按钮到错误提示的间隔时间（虽然很短，假设有工具可以记录）
之后再输入 baaaaa，同样记录时间
重复以上过程直到 gaaaaa，会发现从点击登录按钮到错误提示的间隔时间稍微变长了一些
之后小 B 即知道小 A 的密码第一位是 g，之后重复以上步骤即可破解小 A 的密码。

当然这里的例子很蠢，而且也过于理想化，但足够说明问题。反应快的读者可能马上就会知道为什么在观察 'gaaaaa' 的测量结果后小 B 就会知道小 A 首位密码，这是因为执行校验密码是否正确的代码是需要时间的，因此在理想条件下，首位错误和首位正确第二位错误的反馈结果必然是后者时间略长。

这就是一个比较典型的旁路攻击类型，专业的名称叫做计时攻击（timing attack），有兴趣的可以上网搜索了解详情。

预执行（speculation execution）

之后再来了解预执行这个概念，电脑之所以可以执行我们所编写的代码，其背后是由若干硬件协同工作的结果。其中两个比较重要的，一个是内存，一个是CPU。众所周知，CPU执行计算的速度肯定是远大于它读取内存的速度的，这样的结果就是，CPU在对内存读取某些数据的时候，会闲置，这样变造成了浪费。为了提高性能，现代基本大部分硬件制造商都引入了预执行这个机制来压榨CPU的性能。大概的意思如下，比如你写了一段代码：

if(somethingTrueOrFalse) {
  // TODO ...
}

逻辑上，这个 if 语句内部的代码是否执行，取决于 somethingTrueOrFalse 变量，但是注意，这是逻辑上的，CPU在运行这段代码的时候，可不是这样子的。它可能会直接跳过判定 somethingTrueOrFalse 是真是假的逻辑，直接执行 if 语句内部的代码，之后反过来再根据 somethingTrueOrFalse 的取值情况作出反应，如果为真，则保留执行结果，如果为假，则撤销执行结果。

这里对于预执行的描述是极度简化的，不过足够说明概念了。如果有兴趣可以上网搜索相关文章，尤其是预执行策略方面的，我看了一些，没看完，感觉和AI有的一拼（题外话）。

幽灵和熔断漏洞（Spectre & Meltdown）

这个漏洞是在18年 1 月份被报道出来的，是硬件系统层面的漏洞。关于这个漏洞本身，网上已经有专业的论文对其进行了详尽的介绍，有兴趣可以自行搜索阅读，这里就不展开说了。简单讲，就是结合上文提及的两个概念的两种实际攻击方法。

这里还需要再说一下 CPU 读取数据的方式，CPU 除了利用预执行来提供性能，它本身在从内存读取数据的时候，还会涉及一个缓存的概念。从缓存读取数据的速度是大于内存的，当 CPU 发现将要读取的一个数据在缓存中存在时，它会直接从缓存中读取，这样同样可以提高性能，但是缓存很小同时也很昂贵，所以缓存的大小无法与内存相比。同时，每个程序运行时，CPU 为了防止进程间互相保持独立，它们都拥有属于自己的某块内存区域，假设程序 A 存在一条想要直接越界访问程序 B 内存的指令，这在 CPU 是属于非法的，它不会执行这条指令，而会选择抛出异常并终止程序，然后将其相应的内存数据清零。

之后问题就出现了，假设我们有以下代码：

if (x < arr1.length) {
  y = arr2[arr1[x]]
}

这个例子在参考链接的文章中你可能会多次见到，这里大概解释一下：

arr1 假设是一个比较小的数组，x 是一个我们定义的索引值变量
正常情况下，如果 x 超过 arr1 的长度，程序是要崩溃的，因为它越界了，但是在预执行的前提下，CPU 可能会忽略越界的问题而执行 if 语句内部的代码
arr2 是我们提前声明的一个用来储存数据的数组，它储存于内存的另一个区域，它是连续的，而且我们强制它没有拷贝至缓存，只保存于内存（这点在视频中有提及，我这里强调一下）
之后我们假设 arr1 中的位于 x 索引出的值是 k，那么在预执行的前提下，y = arr2[arr1[x]]等价于y = arr2[k]
然后由于我们会把 arr2[k] 这个值付给另一个变量 y，这里其实算是一个访问值的操作，CPU 后将 arr2[k] 位于内存地址的值转入缓存中，而其余元素保留在内存中（因为并未访问）

之后，只需要遍历 arr2 这个数组，当发现某个索引上的值的访问速度远快于其他索引的访问速度时，这个索引既是我们从越界内存中“偷”到的值。至此，一次攻击就完成了，理论上，利用这个漏洞，可以获取缓存区所有地址的值，其中很有可能包含敏感信息，比如密码什么的。

和浏览器的关系

以chrome 举例（用的人多）

Chrome浏览器在处理不同 tab 和不同页面时，会将为它们划分不同的进程，而且受制于同源策略的影响，这些页面之间本应该互不干扰。但是我们知道，同源策略虽然牛逼，但浏览器中仍然存在一些不受制于它约束的 api、标签，比如常见的 img、iframe 和 script等等。诸如以下代码，不知道看文章的诸位有没有写过，反正我是写过，或者说遇见过：

<img src="https://foo/bar/baz/">

有人可能会问，一个 img 标签你 src 属性不填图片的 uri，你是不是傻。其实不是这样的，有时候对网站做一些跟踪和分析时，确实会这么写，因为浏览器会往https://foo/bar/baz/这个地址发送一个 GET 资源的请求，在服务端我们可以利用这个请求做一些追踪的逻辑，同理 script 也可以完成需求。但是这么做的后果就是，虽然 img 帮我们发送了这个请求，但是它却没有得到所期望格式的资源，所以这里实际可以算作一种错误或者异常。而一些攻击者可以利用这一点，比如，在页面嵌入下面的代码：

<img src="https://example.com/secret.json">

来加载跨域私密文件，因为 img 不受同源策略的制约，这个请求是可以发出去的，服务器响应返回后，显然 secret.json 不是一个图片格式的资源，img 不会显示它，但是并不代表负责渲染当前页面的进程的内存中没有保留关于 secret.json 的数据。因此攻击者可以利用上文中提及的漏洞，编写一些代码来“偷”这些数据，从而造成安全隐患。

而 CORB 的作用就是当浏览器尝试以上面代码的方式加载跨域资源时，在资源未被加载之前进行拦截，从而提升攻击者进行幽灵攻击的成本，这里之所以是说提升成本还非彻底解决是因为这个漏洞是基于硬件层面的，所以软件层面只能做有限的修复，有的人可能马上会说，那 CPU 直接去掉或者用户放弃使用预处理功能不就好了吗？理论上是这样的，但是这将导致预处理带来的性能红利瞬间消失，而且 CPU 的架构设计也不是一天两天就能改的，而且就算改了也没办法一下普及。

哪些内容类型受 CORB 保护

当前有三种内容类型受保护，分别是 json、html 和 xml。关于如何针对每种内容类型 CORB 如何对其进行保护，文档中有详细的章节进行介绍，这里就不多说了。我浏览了一遍，大体的规则均是对内容格式进行一些有针对性的校验，以确认它确实是某个内容类型。这个校验结果最终影响 CORB 的运作方式。

CORB 如何运作

这里我引用文档部分章节并做翻译，关于其中的备注可以直接浏览原文档进行查看。

CORB 会根据如下步骤来确定是否对 response 进行保护（如果响应的内容格式是 json、html 或者 xml）:

如果 response 包含 X-Content-Type-Options: nosniff 响应头部，那么如果 Content-Type 是以下几种的话， response 将受 CORB 保护：

html mime type
xml mime type（除了 image/svg+xml）
json mime type
text/plain

如果 response 的状态是 206，那么如果 Content-Type 是以下几种的话， response 将受 CORB 保护：

html mime type
xml mime type（除了 image/svg+xml）
json mime type

否则，CORB 将尝试探测 response 的 body：

html mime type，并且探测结果是 html 内容格式，response 受 CORB 保护
xml mime type（除了 image/svg+xml）, 并且探测结果是 xml 内容格式，response 受 CORB 保护
json mime type，并且探测结果是 json 内容格式，response 受 CORB 保护
text/plain，并且探测结果是 json、html 或者 xml 内容格式，response 受 CORB 保护
任何以 JSON security prefix 开头的 response（除了 text/css）受 CORB 保护

这里值得一提的是，对于探测是必须的，以防拦截了那些依赖被错误标记的跨源响应的页面（比如，图片资源但是格式却被标记为 text/html）。如果不进行格式探测，那么会有16倍以上的 response 被拦截。

CORB 如何拦截一个响应

当一个 response 被 CORB 保护时，它的 body 会被覆盖为空，同时 headers 也会被移除（当前 Chrome 仍然会保留 Access-Control-* 相关的 headers）。关于 CORB 的工作方式，一定要和 CORS 做区分，因为它要防止这些被拦截的数据进入渲染当前页面进程的内存中，所以它一定不会被加载并读取。这不同于 CORS，因为后者会做一些过滤操作，数据虽然不可被加载，但是可能仍然保留在渲染进程的内存中。

对于其他 web 平台特性的影响

这里仍然是翻译部分文档中的内容，因为本身写的就很细致了。

CORB 不会影响以下技术场景：

XHR and fetch()

CORB 并不会产生显而易见的影响，因为 XHR 和 fetch() 在响应中已经应用了同源策略（比如：CORB 应该仅会拦截那些因缺少 CORS 而发生跨域 XHR 错误的 response）

Prefetch

CORB 会拦截那些到达跨源渲染进程的 response body，但是不会阻止那些被浏览器进程缓存的 response body（然后传递到另一个同源渲染进程）。

Tracking and reporting

当前存在各种各样的技术，尝试对记录用户访问的服务器发送 web 请求，以检查用户是否已访问某些内容。该请求经常使用隐藏的 img 标签进行发送（我前文提及了），然后服务器以 204 状态码或者 html 文档进行响应。除了 img，还可以使用类似 script、style 和别的可用标签。
CORB 不会对这些技术场景造成影响，因为它们不会依赖于服务器返回响应的内容。这一点同样使用与其他类似的技术场景和 web 特性，只要它们不关心响应即可，比如：beacons，ping，CSP违规报告等。

Service workers

Service workers 可以拦截跨源 requests 并在其内部人为地构建 response（没有跨源和安全边界），CORB 不会拦截它们。
当 Service workers 确实缓存了一些跨源的 responses 时，由于这些 responses 对于调用者来讲是透明的，因此 CORB 会拦截它们，但是这并不需要对 Service Worker 作出任何改变。

Blob and File API

即使没有 CORB 的话，获取跨源的 blob URLs 当前也会被拦截。

Content scripts and plugins

它们所属的范围并不含在 CORB 的职责内 —— CORB 假设已经有某种合适的安全策略或安全机制存在于这些 content scripts 和 plugins 中（比如 Adobe Flash 已经实现了类似 CORB 的机制，通过 crossdomain.xml）。

相关文档：

https://chromium.googlesource.com/chromium/src/+/master/services/network/cross_origin_read_blocking_explainer.md

https://www.chromium.org/Home/chromium-security/corb-for-developers

https://zhuanlan.zhihu.com/p/32784852

https://www.chromestatus.com/feature/5629709824032768

CORP (Cross-Origin Resource Policy)

简单的说是一个与上面 CORB 配套的 HTTP 请求头，可以全面阻止跨站/跨域资源请求。

作为CORS之外的一个安全补充。也只对非CORS请求有效

并且由于这个策略是通过响应头表示的，因此实际请求不会受到阻止，相反，浏览器通过删除响应体来防止结果泄漏。

注意: 由于 Chrome 中的一个错误，设置跨原产地资源政策可能会破坏 PDF 渲染，使访问者无法阅读某些 PDF 文件的第一页。在生产环境中使用此消息头时要小心。

Cross-Origin-Resource-Policy: same-site | same-origin | cross-origin

same-site

只有来自同一站点的请求才能读取资源。

警告: 这不如原点安全。检查两个来源是否相同的网站的算法是在 HTML 标准中定义的，包括检查可以注册的域。

same-origin 同源的只有来自相同的请求 origin

(i.e. scheme + host + port) 可以读取资源
cross-origin 交叉起源任何的 origin (同一站点和跨站点)可以读取资源

有兴趣的可以看下

https://github.com/whatwg/fetch/issues/687

https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Cross-Origin_Resource_Policy_(CORP)

COEP（Cross-Origin Embedder Policy）

也是一个 HTTP 请求头，规定了该网页中 iframe 嵌入其它网页是否要也遵循 CORP

有兴趣的可以看下

https://wicg.github.io/cross-origin-embedder-policy/

COOP (Cross Origin Opener Policy)

这些功能强大的特性和 document.domain 修改的预防功能在 Chrome 83版本中还没有启用。预计86可以通过flag打开

规定了 window.opener 能不能跨站/跨域访问、domain 能不能被修改

https://github.com/whatwg/html/pull/5334/files

想翻译一下一直没时间。。https://web.dev/coop-coep/

关于 opener https://mathiasbynens.github.io/rel-noopener/