第三方提供的跨源资源通常未包含足够的 CORP 标头。如果可以在没有凭据的情况下请求这些 API，现在您可以通过对其进行标记来启用跨域隔离。
我们已推出新的跨源嵌入器政策 (COEP) 值
credentialless，以允许浏览器加载
不使用跨源资源政策 (CORP)，即通过发送
Cookie 等凭据这有助于开发者采用跨源
更轻松地进行隔离
为什么需要跨域隔离
有些 Web API 会增加旁路攻击的风险，例如
Spectre。接收者
为降低这种风险，浏览器提供了一个基于选择启用的隔离环境，
跨域隔离借助跨源
隔离状态，网页可以使用特权功能，包括
SharedArrayBuffer、
performance.measureUserAgentSpecificMemory()
以及分辨率更高、精确度高的计时器
同时还会将该来源与其他来源隔离开来（除非相应来源已选择启用）。
网页必须发送两个 HTTP 标头才能启用跨域隔离：
Cross-Origin-Embedder-Policy: require-corp
Cross-Origin-Opener-Policy: same-origin
采用跨源隔离状态时，必须向所有跨源资源提供
或设置要加载的 Cross-Origin-Resource-Policy 标头。
启用跨域隔离功能所面临的挑战
而跨域隔离功能可提高网页的安全性， 支持强大的功能， 规模最大的 需要针对所有跨域配置启用 CORS 或 CORP 框架 资源。不带这些标头的资源 跨源隔离网页
这些跨源资源通常由第三方提供， 并不容易添加必要的标头。
但是，如果我们知道相应资源足够安全，可以加载，该怎么办？事实上，只有 存在风险的资源是使用凭据请求的 可能包含敏感信息，而攻击者无法在其 。这意味着，无需凭据即可请求的资源将公开 可安全地加载
credentialless前去救援
这正是 COEP: credentialless 的用武之地。credentialless 是新值
针对 Cross-Origin-Embedder-Policy 标头。与 require-corp 类似，它可以
启用跨域隔离，但不需要 CORP:cross-origin
标头，这些标头将改为在
凭据（例如 Cookie）。
您也可以使用 以下两个标头：
Cross-Origin-Embedder-Policy: credentialless
Cross-Origin-Opener-Policy: same-origin
这意味着请求的跨源服务器无法使用 敏感资源，请求者始终可以假定响应 包含公开信息。
这也与逐步淘汰第三方 Cookie 的计划。
演示
您可以在此演示中试用各种标题选项： https://cross-origin-isolation.glitch.me
常见问题解答
我可以在 credentialless 环境下发送凭据化请求吗？
当然可以，代价是会改变请求的模式，需要进行 CORS 检查
。对于 HTML 标记，例如 <audio>、<img>、<link>、<script>，
和 <video>，只需明确附加 crossorigin="use-credentials" 即可
浏览器以发送凭据化请求。
例如，即使 https://www.example.com 上的文档包含
Cross-Origin-Embedder-Policy: credentialless标头，<img
src="https://images.example.com/avatar.png" crossorigin="use-credentials">将
发送一个带有凭据的请求。
对于 fetch() API，可以使用 request.mode = 'cors'。
提供了 COEP: credentialless，您认为 COEP: require-corp 对我的网站仍然有用吗？
COEP: require-corp 不需要您手动将请求模式切换为
CORS（如果某些跨源子资源需要 Cookie）。
我是否可以在 credentialless 环境下加载没有特殊标头的跨源 iframe？
不需要。在 credentialless 环境下加载跨源 iframe 仍需遵循与 require-corp 相同的条件。iframe 文档需要使用两个标头：
Cross-Origin-Embedder-Policy: credentialless（或require-corp）Cross-Origin-Resource-Policy: cross-origin
好消息是，关于允许加载 iframe 而不允许加载跨源 iframe 的讨论（通过为 iframe 提供 crossorigin="anonymous" 时）。
这将允许在不使用标头的情况下加载跨源 iframe
凭据。
其他浏览器是否会采用此功能？
- Firefox 跟踪问题
- Webkit 请求定位：无信号
- W3C 代码请求位置： 待定
即将推出
我们还将进一步更新两项更新，以缓解 跨域隔离：
已报名参加 Chrome 源试用以延长 SharedArrayBuffer 变更的用户，原因如下： 你可能想知道它何时会被终止。最初我们 但我们已宣布将在 Chrome 96 中终止该应用，但 则将其推迟到 Chrome 106。
资源
- 将您的网站设为“跨源隔离”（使用 COOP 和 COEP）
- 为什么需要“跨源隔离”实现强大功能
- 启用跨域隔离的指南
- Android Chrome 88 和桌面版 Chrome 92 中的 SharedArrayBuffer 更新
照片提供者：Martin Adams 已开启 不启动