了解为什么需要跨域隔离才能使用 SharedArrayBuffer、performance.measureUserAgentSpecificMemory() 和更精确的高分辨率计时器等强大功能。
简介
在将您的网站设置为“跨域隔离”使用 COOP 和 COEP 解释了如何采用 “独立”使用 COOP 和 COEP 处理状态。这是一篇配套文章 为什么需要跨域隔离才能在浏览器中启用强大的功能。
背景
网站建立在同源的基础上
政策：一项安全功能，
文档和脚本如何与来自其他来源的资源进行交互。这个
原则限制了网站访问跨源资源的方式。对于
例如，来自 https://a.example 的文档被禁止访问数据
托管在 https://b.example 上。
不过，同源政策曾出现过一些例外情况。任何网站都可以：
- 嵌入跨源 iframe
- 包含跨源资源，例如图片或脚本
- 使用 DOM 引用打开跨源弹出式窗口
如果网页完全可以从头开始设计，就不会存在这些例外情况。 遗憾的是，当网络社区意识到 严格的同源政策，那么网络原本就已经依赖于这些例外情况。
这种宽松的同源政策的安全副作用已在以下两个部分中进行了修补：
方法。其中一种方式是引入一个名为跨网站转化的新协议
源资源共享 (CORS)
目的是确保服务器允许与
指定来源。另一种方法是隐式取消对脚本的
同时保持向后兼容性。此类
我们把跨源资源称为“不透明”资源。例如，这就是
通过 CanvasRenderingContext2D 操控跨源图片的像素
失败，除非对映像应用了 CORS。
所有这些政策决策都是在浏览上下文组中做出的。
很长时间以来，结合使用 CORS 和不透明资源足以 浏览器的安全性。有时是极端情况（如 JSON 漏洞） 并且需要修补，但总体而言， “允许直接读取跨源资源的原始字节”之前 成功。
这一切都改变了
Spectre：
将任何与您的代码加载到同一浏览上下文组的数据
可能可读。通过测量某些操作所花费的时间，攻击者
就可以猜测 CPU 缓存的内容，通过这些内容，
进程内存。低粒度计时器可能会发生此类计时攻击
但可通过高粒度计时器加快速度，
显式（如 performance.now()）和隐式（如
SharedArrayBuffer）。如果 evil.com 嵌入了跨源图片，则可以使用
幽灵攻击读取其像素数据，使保护机制依赖于
“不透明”无效。
理想情况下，所有跨源请求都应由服务器进行明确审查 拥有该资源的权限。如果审查并非由 那么数据就永远不会进入浏览页面 邪恶势力的环境组，因此将远离任何幽灵 网页可进行的攻击。我们称之为跨源隔离状态。 这正是 COOP+COEP 的目的所在。
在跨域隔离状态下，发出请求的网站会被视为不太
危险，则会解锁强大的功能，例如SharedArrayBuffer、
performance.measureUserAgentSpecificMemory()和高分辨率
计时器的精确度更高，
可能会用于类似幽灵的攻击。还会禁止修改
document.domain。
跨源嵌入器政策
跨源嵌入器 政策 (COEP) 可防止出现 文档加载任何未明确授权的跨源资源 文档权限（使用 CORP 或 CORS）。借助此功能，您可以声明 文档无法加载这类资源。
如需激活此政策，请将以下 HTTP 标头附加到文档：
Cross-Origin-Embedder-Policy: require-corp
require-corp 关键字是 COEP 唯一可接受的值。这会强制
指定文档只能从同一来源加载资源，或
明确标记为可从另一来源加载的资源。
若想从其他来源加载资源，这些资源需要支持 跨域资源共享 (CORS) 或跨域资源政策 (CORP)。
跨域资源共享
如果跨源资源支持跨源资源共享
(CORS)，那么您可以使用
crossorigin
属性
在不被 COEP 屏蔽的情况下将其加载到您的网页。
<img src="https://third-party.example.com/image.jpg" crossorigin>
例如，如果通过 CORS 标头传送此图片资源，请使用
crossorigin 属性，以便获取资源的请求将使用 CORS
模式。这也
会阻止加载图片，除非设置了 CORS 标头。
同样，您可以通过 fetch() 方法提取跨源数据，
不需要特殊处理，只要服务器以正确的
HTTP
标头。
跨域资源政策
跨域资源政策 （公司） 最初是作为一项可选功能而推出的，目的是防止您的资源 由其他来源加载。在 COEP 上下文中，CORP 可以指定 所有者政策，规定谁可以加载资源。
Cross-Origin-Resource-Policy 标头采用三个可能的值：
Cross-Origin-Resource-Policy: same-site
标记为 same-site 的资源只能从同一网站加载。
Cross-Origin-Resource-Policy: same-origin
标记为 same-origin 的资源只能从同一来源加载。
Cross-Origin-Resource-Policy: cross-origin
任何网站都可以加载标记为 cross-origin 的资源。（
值已添加到
CORP 规格和 COEP。）
跨源打开者政策
跨源打开者政策
(COOP)
通过将顶级窗口放入其他文档
不同的浏览上下文组，这样他们就无法直接与
顶级窗口。例如，如果某个使用 COOP 的文档打开一个弹出式窗口，其
window.opener 属性将为 null。此外，此 API 的 .closed 属性
opener 对它的引用将返回 true。
Cross-Origin-Opener-Policy 标头采用三个可能的值：
Cross-Origin-Opener-Policy: same-origin
标记为 same-origin 的文档可以共享相同的浏览上下文
包含同源文档，并且还明确标记为 same-origin 的群组。
Cross-Origin-Opener-Policy: same-origin-allow-popups
包含 same-origin-allow-popups 的顶级文档会保留对
不设置 COOP 或通过
将 COOP 设置为 unsafe-none。
Cross-Origin-Opener-Policy: unsafe-none
unsafe-none 是默认值，允许将文档添加到其打开者的
浏览上下文组，除非打开程序本身的 COOP 为 same-origin。
摘要
如果您想确保自己能使用 SharedArrayBuffer 等强大功能，
performance.measureUserAgentSpecificMemory()或高分辨率
精确程度更高的计时器，只需记住
您的文档需要同时使用值为 require-corp 的 COEP 和
值为 same-origin 的 COOP。如果两者都不存在，浏览器就会
无法保证充分隔离来安全启用这些强大的功能。您
您可通过查看
self.crossOriginIsolated
返回 true。
如需了解实现此功能的步骤，请参阅将您的网站设为“跨源” “独立”（使用 COOP 和 COEP）。