跳转到主要内容

标签(标签)

资源精选(342) Go开发(108) Go语言(103) Go(99) angular(82) LLM(78) 大语言模型(63) 人工智能(53) 前端开发(50) LangChain(43) golang(43) 机器学习(39) Go工程师(38) Go程序员(38) Go开发者(36) React(33) Go基础(29) Python(24) Vue(22) Web开发(20) Web技术(19) 精选资源(19) 深度学习(19) Java(18) ChatGTP(17) Cookie(16) android(16) 前端框架(13) JavaScript(13) Next.js(12) 安卓(11) 聊天机器人(10) typescript(10) 资料精选(10) NLP(10) 第三方Cookie(9) Redwoodjs(9) ChatGPT(9) LLMOps(9) Go语言中级开发(9) 自然语言处理(9) PostgreSQL(9) 区块链(9) mlops(9) 安全(9) 全栈开发(8) OpenAI(8) Linux(8) AI(8) GraphQL(8) iOS(8) 软件架构(7) RAG(7) Go语言高级开发(7) AWS(7) C++(7) 数据科学(7) whisper(6) Prisma(6) 隐私保护(6) JSON(6) DevOps(6) 数据可视化(6) wasm(6) 计算机视觉(6) 算法(6) Rust(6) 微服务(6) 隐私沙盒(5) FedCM(5) 智能体(5) 语音识别(5) Angular开发(5) 快速应用开发(5) 提示工程(5) Agent(5) LLaMA(5) 低代码开发(5) Go测试(5) gorm(5) REST API(5) kafka(5) 推荐系统(5) WebAssembly(5) GameDev(5) CMS(5) CSS(5) machine-learning(5) 机器人(5) 游戏开发(5) Blockchain(5) Web安全(5) Kotlin(5) 低代码平台(5) 机器学习资源(5) Go资源(5) Nodejs(5) PHP(5) Swift(5) devin(4) Blitz(4) javascript框架(4) Redwood(4) GDPR(4) 生成式人工智能(4) Angular16(4) Alpaca(4) 编程语言(4) SAML(4) JWT(4) JSON处理(4) Go并发(4) 移动开发(4) 移动应用(4) security(4) 隐私(4) spring-boot(4) 物联网(4) nextjs(4) 网络安全(4) API(4) Ruby(4) 信息安全(4) flutter(4) RAG架构(3) 专家智能体(3) Chrome(3) CHIPS(3) 3PC(3) SSE(3) 人工智能软件工程师(3) LLM Agent(3) Remix(3) Ubuntu(3) GPT4All(3) 软件开发(3) 问答系统(3) 开发工具(3) 最佳实践(3) RxJS(3) SSR(3) Node.js(3) Dolly(3) 移动应用开发(3) 低代码(3) IAM(3) Web框架(3) CORS(3) 基准测试(3) Go语言数据库开发(3) Oauth2(3) 并发(3) 主题(3) Theme(3) earth(3) nginx(3) 软件工程(3) azure(3) keycloak(3) 生产力工具(3) gpt3(3) 工作流(3) C(3) jupyter(3) 认证(3) prometheus(3) GAN(3) Spring(3) 逆向工程(3) 应用安全(3) Docker(3) Django(3) R(3) .NET(3) 大数据(3) Hacking(3) 渗透测试(3) C++资源(3) Mac(3) 微信小程序(3) Python资源(3) JHipster(3) 语言模型(2) 可穿戴设备(2) JDK(2) SQL(2) Apache(2) Hashicorp Vault(2) Spring Cloud Vault(2) Go语言Web开发(2) Go测试工程师(2) WebSocket(2) 容器化(2) AES(2) 加密(2) 输入验证(2) ORM(2) Fiber(2) Postgres(2) Gorilla Mux(2) Go数据库开发(2) 模块(2) 泛型(2) 指针(2) HTTP(2) PostgreSQL开发(2) Vault(2) K8s(2) Spring boot(2) R语言(2) 深度学习资源(2) 半监督学习(2) semi-supervised-learning(2) architecture(2) 普罗米修斯(2) 嵌入模型(2) productivity(2) 编码(2) Qt(2) 前端(2) Rust语言(2) NeRF(2) 神经辐射场(2) 元宇宙(2) CPP(2) 数据分析(2) spark(2) 流处理(2) Ionic(2) 人体姿势估计(2) human-pose-estimation(2) 视频处理(2) deep-learning(2) kotlin语言(2) kotlin开发(2) burp(2) Chatbot(2) npm(2) quantum(2) OCR(2) 游戏(2) game(2) 内容管理系统(2) MySQL(2) python-books(2) pentest(2) opengl(2) IDE(2) 漏洞赏金(2) Web(2) 知识图谱(2) PyTorch(2) 数据库(2) reverse-engineering(2) 数据工程(2) swift开发(2) rest(2) robotics(2) ios-animation(2) 知识蒸馏(2) 安卓开发(2) nestjs(2) solidity(2) 爬虫(2) 面试(2) 容器(2) C++精选(2) 人工智能资源(2) Machine Learning(2) 备忘单(2) 编程书籍(2) angular资源(2) 速查表(2) cheatsheets(2) SecOps(2) mlops资源(2) R资源(2) DDD(2) 架构设计模式(2) 量化(2) Hacking资源(2) 强化学习(2) flask(2) 设计(2) 性能(2) Sysadmin(2) 系统管理员(2) Java资源(2) 机器学习精选(2) android资源(2) android-UI(2) Mac资源(2) iOS资源(2) Vue资源(2) flutter资源(2) JavaScript精选(2) JavaScript资源(2) Rust开发(2) deeplearning(2) RAD(2)

category

使用COOP和COEP来建立一个跨原点的隔离环境,并以更好的精度启用强大的功能,如SharedArray Buffer、performance.measureUserAgentSpecificMemory()和高分辨率计时器。


注意:Chrome桌面上的SharedArrayBuffer需要从Chrome 92开始进行跨源隔离。在Android Chrome 88和Desktop Chrome 92中的SharedArray Buffer更新中了解更多信息。

更新

  • 2022年6月21日:启用跨源隔离时,工作脚本也需要小心。添加了一些解释。
  • 2021年8月5日:JS Self-Profiling API被提到是需要交叉源隔离的API之一,但反映了最近方向的变化,它被删除了。
  • 2021年5月6日:根据反馈和报告的问题,我们决定调整在Chrome M92中限制非跨源隔离站点中使用SharedArray Buffer的时间表。
  • 2021年4月16日:添加了关于新的COEP无证书模式和COOP同源的注释,允许弹出窗口成为跨源隔离的放松条件。
  • 2021年3月5日:删除了SharedArray Buffer、performance.measureUserAgentSpecificMemory()和调试功能的限制,这些功能现在已在Chrome 89中完全启用。添加了即将推出的功能performance.now()和performance.timeOrigin,它们将具有更高的精度。
  • 2021年2月19日:添加了关于功能策略allow=“跨源隔离”和DevTools上调试功能的说明。
  • 2020年10月15日:self.crossOriginIsolated可从Chrome 87获得。反映这一点的是,当self.crossOriginIsolated返回true时,document.domain是不可变的。performance.measureUserAgentSpecificMemory()正在结束其原始试用,并且在Chrome 89中默认启用。Android Chrome上的共享数组缓冲区将从Chrome 88开始提供。

一些web API增加了像Spectre这样的侧通道攻击的风险。为了降低这种风险,浏览器提供了一个基于选择加入的隔离环境,称为跨源隔离。在跨来源隔离状态下,网页将能够使用特权功能,包括:

 

API Description
SharedArrayBuffer Required for WebAssembly threads. This is available from Android Chrome 88. Desktop version is currently enabled by default with the help of Site Isolation, but will require the cross-origin isolated state and will be disabled by default in Chrome 92.
performance.measureUserAgentSpecificMemory() Available from Chrome 89.
performance.now()performance.timeOrigin Currently available in many browsers with the resolution limited to 100 microseconds or higher. With cross-origin isolation, the resolution can be 5 microseconds or higher.
Features that will be available behind cross-origin isolated state.

跨原点隔离状态还防止修改document.domain。(能够更改文档.domain允许在同一站点文档之间进行通信,这被认为是同源政策中的一个漏洞。)

要选择进入跨源隔离状态,您需要在主文档上发送以下HTTP标头:

Cross-Origin-Embedder-Policy: require-corp
Cross-Origin-Opener-Policy: same-origin


这些标题指示浏览器阻止加载未选择由跨来源文档加载的资源或iframe,并阻止跨来源窗口与您的文档直接交互。这也意味着那些跨来源加载的资源需要选择加入。

您可以通过检查self.crossOriginIsolated来确定网页是否处于跨原点隔离状态。

本文展示了如何使用这些新标头。在后续文章中,我将提供更多的背景和背景。

注意:本文针对的是那些希望在浏览器平台上以更稳健的方式使用SharedArray Buffer、WebAssembly线程、performance.measureUserAgentSpecificMemory()或高精度计时器的网站。


关键词:这篇文章使用了许多听起来相似的术语。为了让事情更清楚,让我们先定义它们:*COEP:跨来源嵌入器策略*COOP:跨来源开放器策略*CORP:跨起源资源策略*CORS:跨来源资源共享*CORB:跨来源读取阻塞


部署COOP和COEP,使您的网站跨源隔离


注意:在启用跨源隔离指南中学习启用跨源分离的实用步骤。

集成COOP和COEP


1.设置跨来源Opener策略:在顶层文档上设置同源头


通过在顶级文档上启用 COOP: same-origin,具有相同原点的窗口和从文档打开的窗口将具有单独的浏览上下文组,除非它们位于相同原点且具有相同的COOP设置。因此,对打开的窗口强制隔离,并禁用两个窗口之间的相互通信。

注意:这将破坏需要跨来源窗口交互(如OAuth和支付)的集成。为了缓解这个问题,我们正在探索放宽条件,使跨来源隔离成为跨来源开放者政策:同源允许弹出窗口。通过这种方式,可以与自己打开的窗口进行通信。如果您想启用跨来源隔离,但被此问题阻止,我们建议您注册来源试验,并等待新条件可用。在这个问题得到安全解决之前,我们不打算终止原产地试验。


浏览上下文组是一组可以相互引用的窗口。例如,通过<iframe>嵌入的顶级文档及其子文档。如果是网站(https://a.example)打开一个弹出窗口(https://b.example),打开窗口和弹出窗口共享相同的浏览上下文,因此它们可以通过window.opener等DOM API相互访问。

 

您可以从DevTools中检查窗口开启器及其开启器是否在单独的浏览上下文组中。

试试看:看看不同COOP参数的影响


2.确保资源已启用CORP或CORS


确保页面中的所有资源都加载了CORP或CORS HTTP标头。这一步骤是启用COEP的第四步所必需的。

根据资源的性质,您需要执行以下操作:

  • 如果希望仅从同一来源加载资源,请设置 cross-Origin-Resource-Policy: same-origin标头。
  • 如果希望仅从同一站点但跨来源加载资源,请设置Cross-Origin-Resource-Policy: same-site标头。
  • 如果资源是从您控制的跨来源加载的,请尽可能设置Cross-Origin-Resource-Policy: cross-origin标头。
  • 对于无法控制的跨来源资源:
    • 如果资源由CORS提供,请在加载HTML标记中使用crossorgin属性。(例如,<img src=“***”crossorgin>。)
    • 请资源所有者支持CORS或CORP。
  • 对于iframe,请遵循以上相同的原则,并设置Cross-Origin-Resource-Policy: cross-origin(或same-sitesame-origin,取决于上下文)。
  • 用WebWorker加载的脚本必须来自同一来源,所以您不需要CORP或CORS头。
  • 对于使用COEP: require-corp服务的文档或工作人员,在没有CORS的情况下加载的跨来源子资源必须设置Cross-Origin-Resource-Policy: cross-origin 标头以选择嵌入。例如,这适用于<script>、importScripts、<link>、<video>、<iframe>等。


您可以对嵌入iframe中的文档启用跨源隔离,方法是对<iframe>标记应用allow="cross-origin-isolated"权限策略,并满足本文档中描述的相同条件。请注意,包括父框架和子框架在内的整个文档链也必须是跨原点隔离的。


关键词:了解“同一站点”和“同源”之间的区别很重要。在了解相同的网站和相同的来源了解差异。

3.使用COEP Report Only HTTP头来评估嵌入的资源


在完全启用COEP之前,您可以通过使用Cross Origin Embedder Policy Report Only标头来检查策略是否真的有效,从而进行试运行。您将在不阻止嵌入内容的情况下收到报告。

递归地将其应用于所有文档,包括顶级文档、iframe和辅助脚本。有关Report-Only HTTP标头的信息,请参阅使用Reportingneneneba API观察问题。

4.启用COEP


一旦您确认一切正常,并且所有资源都可以成功加载,请将Cross-Origin-Embedder-Policy-Report-Only标头切换到与所有文档(包括通过iframe和worker脚本嵌入的文档)具有相同值的Cross-Origin-Embedder-Policy标头。

试试看:看看不同COEP/CORP参数的影响


注意:Squoosh(一种图像优化PWA)现在使用COOP/COEP在Android Chrome上访问Wasm线程(和共享阵列缓冲区)。


注意:我们一直在探索大规模部署跨源资源策略的方法,因为跨源隔离要求所有子资源都明确选择加入。我们想出了相反的想法:一种新的COEP“无凭据”模式,允许通过剥离所有凭据来加载没有CORP头的资源。我们希望这将减轻您确保子资源发送跨来源资源策略标头的负担。然而,由于无证书模式在Chrome 96版中可用,但尚未被任何其他浏览器支持,一些开发人员可能会发现部署COOP或COEP很有挑战性。如果您不想启用跨来源隔离,我们建议您注册来源试用版,并等待更多浏览器提供无证书服务。


确定self.crossOriginIsolated的隔离是否成功


当网页处于跨原点隔离状态,并且所有资源和窗口都隔离在同一浏览上下文组中时,self.crossOriginIsolated属性返回true。您可以使用此API来确定是否已成功隔离浏览上下文组并获得对performance.measureUserAgentSpecificMemory()等强大功能的访问权限。

对于在屏幕上呈现的资源(如图像),检测COEP问题相当容易,因为请求将被阻止,并且页面将指示缺少图像。然而,对于不一定具有视觉影响的资源,如脚本或样式,COEP问题可能会被忽视。对于这些,请使用DevTools网络面板。如果COEP有问题,您应该在Status列中看到(blocked:NotSameOriginalAfterDefaultedToSameOriginByCoep)。

“网络”面板的“状态”列中的COEP问题。
然后,您可以单击条目以查看更多详细信息。

单击“网络”面板中的网络资源后,COEP问题的详细信息显示在Headers选项卡中。
您还可以通过应用程序面板确定iframe和弹出窗口的状态。转到左侧的“框架”部分,展开“顶部”以查看资源结构的细分。

您可以检查iframe的状态,例如SharedArray Buffer的可用性等。

Chrome DevTools iframe检查器
您还可以检查弹出窗口的状态,例如是否跨原点隔离。

Chrome DevTools弹出窗口检查器


使用报告API观察问题


Reportingneneneba API是另一种可以检测各种问题的机制。您可以配置Reportingneneneba API来指示用户浏览器在COEP阻止加载资源或COOP隔离弹出窗口时发送报告。Chrome从69版开始就支持Reportingneneneba API,用于各种用途,包括COEP和COOP。

注意:您是否已经使用带有Report-To头的Reportingneneneba API?Chrome正在过渡到新版本的Reportingneneneba API,用Reporting-Endpoints取代Report-to;考虑迁移到新版本。有关详细信息,请参阅迁移到报告API v1。
要了解如何配置Reporting API并设置接收报告的服务器,请转到使用Reporting API。

COEP报告示例


当跨来源资源被阻止时,一个示例COEP报告负载如下所示:

[{
  "age": 25101,
  "body": {
    "blocked-url": "https://third-party-test.glitch.me/check.svg?",
    "blockedURL": "https://third-party-test.glitch.me/check.svg?",
    "destination": "image",
    "disposition": "enforce",
    "type": "corp"
  },
  "type": "coep",
  "url": "https://cross-origin-isolation.glitch.me/?coep=require-corp&coop=same-origin&",
  "user_agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4249.0 Safari/537.36"
}]


注意:被阻止的url只是为了向后兼容,最终会被删除。

COOP报告示例


孤立打开弹出窗口时的示例COOP报告负载如下所示:

[{
  "age": 7,
  "body": {
    "disposition": "enforce",
    "effectivePolicy": "same-origin",
    "nextResponseURL": "https://third-party-test.glitch.me/popup?report-only&coop=same-origin&",
    "type": "navigation-from-response"
  },
  "type": "coop",
  "url": "https://cross-origin-isolation.glitch.me/coop?coop=same-origin&",
  "user_agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4246.0 Safari/537.36"
}]


当不同的浏览上下文组试图相互访问时(仅在“仅报告”模式下),COOP也会发送报告。例如,尝试postMessage()时的报告如下所示:

[{
  "age": 51785,
  "body": {
    "columnNumber": 18,
    "disposition": "reporting",
    "effectivePolicy": "same-origin",
    "lineNumber": 83,
    "property": "postMessage",
    "sourceFile": "https://cross-origin-isolation.glitch.me/popup.js",
    "type": "access-from-coop-page-to-openee"
  },
  "type": "coop",
  "url": "https://cross-origin-isolation.glitch.me/coop?report-only&coop=same-origin&",
  "user_agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4246.0 Safari/537.36"
},
{
  "age": 51785,
  "body": {
    "disposition": "reporting",
    "effectivePolicy": "same-origin",
    "property": "postMessage",
    "type": "access-to-coop-page-from-openee"
  },
  "type": "coop",
  "url": "https://cross-origin-isolation.glitch.me/coop?report-only&coop=same-origin&",
  "user_agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4246.0 Safari/537.36"
}]


结论


使用COOP和COEPHTTP头的组合可以将网页选择为特殊的跨源隔离状态。您将能够检查self.crossOriginIsolated,以确定网页是否处于交叉源隔离状态。

随着新功能可用于这种跨源隔离状态,我们将不断更新这篇文章,并围绕COOP和COEP对DevTools进行进一步改进。

资源

文章链接