Front-End-Checklist 跨源隔离实战指南COOP、COEP 与 CORP 的正确启用方式【免费下载链接】Front-End-Checklist The essential checklist for modern web development, for humans and AI agents项目地址: https://gitcode.com/gh_mirrors/fr/Front-End-Checklist本文基于 Front-End-Checklist 仓库中的 cross-origin-isolation 规则技能 及其完整规则参考讲清跨源隔离cross-origin isolation的安全价值、三个核心 HTTP 头COOP/COEP/CORP的协作方式、上线前必须完成的第三方资源审计以及通过self.crossOriginIsolated做运行时验证的完整方法论。读完后你将掌握一套“先审计、再启用、后验证”的隔离上线流程并能将该规则应用于安全敏感、重度依赖 SharedArrayBuffer 或 Worker 的前端项目。什么是跨源隔离为什么它不是默认选项跨源隔离cross-origin isolation并不是每个站点都必须的硬性要求但对于处理敏感数据、需要更强 opener 隔离、或依赖浏览器以crossOriginIsolated为前提门控的高能力 API 的应用它是一次有意义的加固步骤。其核心前提是刻意部署deliberate rollout——任何一个不兼容的第三方资源都可能在启用后直接破坏页面。该规则在 Front-End-Checklist 中被标记为优先级 medium · 难度 advanced · 预计耗时 30 分钟适用于安全敏感应用、SharedArrayBuffer 使用方、Worker 密集型应用、编辑器或需要跨源隔离的度量功能场景。COOP 和 COEP 改变了浏览器如何对文档进行分组以及允许哪些跨源资源被嵌入。配合兼容的子资源响应它们能够更好地防御基于 opener 的跨源攻击和 XS-Leak跨源信息泄漏解锁某些高能力特性例如 SharedArrayBuffer现代浏览器将其置于隔离门控之后明确“哪些第三方资源可以加入页面”的信任边界同时带来更高的部署风险——如果未先审计资源、弹窗和嵌入启用即可能引发故障。快速参考Quick Reference规则技能文件给出了四条可直接执行的要点需要跨源隔离时同时使用Cross-Origin-Opener-Policy与Cross-Origin-Embedder-Policy在强制启用 COEP 之前审计每一个跨源 script、iframe、image、worker 和 font可嵌入资源按需使用 CORS 或Cross-Origin-Resource-Policy提供服务在依赖“仅限隔离环境”的特性之前先验证self.crossOriginIsolated true。核心头配置与运行时验证跨源隔离的标准头部组合是三组头各司其职文档响应携带 COOP COEP声明该文档希望与同源文档归组、并限制可嵌入的跨源资源Cross-Origin-Opener-Policy: same-origin Cross-Origin-Embedder-Policy: require-corp子资源响应携带 CORP表明该资源允许被哪些跨源文档引用Cross-Origin-Resource-Policy: same-origin在require-corp模式下页面下加载的每个跨源资源都必须通过 CORS 或 CORP 明确“加入”该页面。启用后应在浏览器中确认真的进入了隔离状态console.log(self.crossOriginIsolated)规则参考文档还给出了一个防御性的运行时常量检查模式适合用于依赖隔离特性的模块入口处if (!self.crossOriginIsolated) { console.warn(This page is not cross-origin isolated yet.) }这三个头的工作关系可以概括为COOP 决定“这份文档与谁隔离 opener 关系”COEP 决定“这份文档允许嵌入什么跨源内容”CORP 则站在资源一侧回答“这个资源允许被哪些文档使用”。三者组合后浏览器才会将顶层文档标记为 cross-origin isolatedcrossOriginIsolated才会为true。上线最佳实践1. 只在文档真正需要隔离时成对启用 COOP 与 COEP完整跨源隔离的常见模式就是上文的same-originrequire-corp组合启用后立刻用console.log(self.crossOriginIsolated)验证。只有看到true隔离才真正生效——头部出现在响应里不等于隔离生效。2. 先审计每一个跨源依赖COEP 改变了页面允许嵌入的内容范围。上线前需要逐项审查scripts第三方脚本、分析脚本fontsimagesiframesworkers分析工具与 tag-manager 类集成任何在 COEP 下加载的跨源资源都必须通过 CORS 或 CORP 主动声明兼容。这是“一个不兼容的第三方脚本就能毁掉整页”风险的主要来源。3. 谨慎处理弹窗流程OAuth、支付、客服等弹窗流程往往依赖 opener 关系。如果应用依赖这些行为必须在强制 COOP 之前显式测试这些流程并选择最窄的兼容设置。验收阈值与例外情况规则文档给出了明确的通过/失败判定标准这也是代码审查时可以落地的验收清单通过Pass预期路由返回兼容的 COOP 与 COEP 头且在需要隔离的位置self.crossOriginIsolated true。失败Fail应用依赖仅限隔离环境的 API但运行时实际并未进入跨源隔离状态强制头部组合下关键的弹窗或嵌入流程被破坏。同时规则也明确列出了应当不启用或谨慎启用的情形大多数站点不需要完整跨源隔离。只有当你真正需要这个安全边界或被门控的浏览器能力时才启用不要把它当作“时髦的默认项”如果只有应用的一小部分需要隔离特性路由级route-specific灰度比全局开启更安全某些第三方内容在 COEP 下就是无法工作。可能需要先替换或隔离该依赖再推进上线。验证方式自动化检查与人工检查规则将验证拆为两层且特别强调“隔离应由运行时行为如self.crossOriginIsolated来证明而不是只看响应头”。自动化检查检查代表性文档响应确认在预期位置存在 COOP 和 COEP检查关键子资源响应确认其提供了兼容的 CORS 或 CORP 行为。人工检查在浏览器中打开页面并检查self.crossOriginIsolated在预发环境中测试弹窗、OAuth、支付、分析与嵌入流程若应用依赖隔离专用 API 而self.crossOriginIsolated仍为false或关键第三方集成停止工作则判定上线失败。该规则在 Front-End-Checklist 仓库中的实现形态Front-End-Checklist 的核心设计是把检查清单同时服务于人类与 AI Agent。跨源隔离规则在仓库中呈现为三层结构理解这一结构有助于复用该规则到其他项目1. 规则源文件MDX规则的单一事实来源是 packages/content/rules/en/security/cross-origin-isolation.mdx。其 frontmatter 声明了categoriessecurity/javascript、subcategory: headers、priority、difficulty、estimatedTime以及供 Agent 使用的promptscheck/fix/explain/codeReview 四个动作的提示词与aiContext适用场景描述。这正是上文 Quick Reference 与“Check/Fix/Explain/Code Review”四段的来源。2. 生成的 Agent 技能Skills仓库通过 scripts/generate/generate-skills.ts 将每条规则 MDX 转换为skills/{slug}/目录SKILL.md承载 frontmatter 摘要与四段式提示词references/rule.md承载完整规则正文。从源码结构看buildSkillMd()会把aiContext规范化为 “Use when …” 开头的描述以便 Agent 意图匹配并把 TL;DR 列表渲染为## Quick ReferencebuildReferencesMd()则通过stripMdxToMarkdown()把 MDX 正文转为纯 Markdown。也就是说skills/cross-origin-isolation/SKILL.md 与其 references/rule.md 是从 MDX 规则文件生成并同步维护的产物。3. 关联规则Related Rules规则 frontmatter 中的relatedRules声明了四条同域规则构成了完整的浏览器隔离审查面关联规则关联理由content-security-policy两者都是基于头部的浏览器加固措施都应通过真实响应验证来落地permissions-policy高能力浏览器特性应在任何跨源隔离上线时被刻意限制cross-origin-securityCORS、postMessage 与 opener 行为与 COOP/COEP/CORP 作用于同一信任边界x-frame-options嵌入策略与 opener 隔离是不同控制手段但属于同一次浏览器隔离审查小结跨源隔离是一条“安全收益明确、部署风险同样明确”的加固路线。Front-End-Checklist 给出的方法论可浓缩为四步判断是否需要处理敏感数据、需要 opener 隔离、依赖 SharedArrayBuffer 等门控能力→审计全部跨源依赖scripts/fonts/images/iframes/workers/分析集成→成对启用 COOP COEP 并让子资源以 CORS/CORP 显式兼容优先路由级灰度显式测试弹窗与 OAuth 流程→用self.crossOriginIsolated true而非响应头作为生效证据。仓库中该规则的 MDX 源文件、生成脚本与技能产物三者保持一致也为将这条检查项接入团队评审流程或 AI 审计流程提供了可直接参考的实现样本。【免费下载链接】Front-End-Checklist The essential checklist for modern web development, for humans and AI agents项目地址: https://gitcode.com/gh_mirrors/fr/Front-End-Checklist创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Front-End-Checklist 跨源隔离实战指南：COOP、COEP 与 CORP 的正确启用方式
Front-End-Checklist 跨源隔离实战指南COOP、COEP 与 CORP 的正确启用方式【免费下载链接】Front-End-Checklist The essential checklist for modern web development, for humans and AI agents项目地址: https://gitcode.com/gh_mirrors/fr/Front-End-Checklist本文基于 Front-End-Checklist 仓库中的 cross-origin-isolation 规则技能 及其完整规则参考讲清跨源隔离cross-origin isolation的安全价值、三个核心 HTTP 头COOP/COEP/CORP的协作方式、上线前必须完成的第三方资源审计以及通过self.crossOriginIsolated做运行时验证的完整方法论。读完后你将掌握一套“先审计、再启用、后验证”的隔离上线流程并能将该规则应用于安全敏感、重度依赖 SharedArrayBuffer 或 Worker 的前端项目。什么是跨源隔离为什么它不是默认选项跨源隔离cross-origin isolation并不是每个站点都必须的硬性要求但对于处理敏感数据、需要更强 opener 隔离、或依赖浏览器以crossOriginIsolated为前提门控的高能力 API 的应用它是一次有意义的加固步骤。其核心前提是刻意部署deliberate rollout——任何一个不兼容的第三方资源都可能在启用后直接破坏页面。该规则在 Front-End-Checklist 中被标记为优先级 medium · 难度 advanced · 预计耗时 30 分钟适用于安全敏感应用、SharedArrayBuffer 使用方、Worker 密集型应用、编辑器或需要跨源隔离的度量功能场景。COOP 和 COEP 改变了浏览器如何对文档进行分组以及允许哪些跨源资源被嵌入。配合兼容的子资源响应它们能够更好地防御基于 opener 的跨源攻击和 XS-Leak跨源信息泄漏解锁某些高能力特性例如 SharedArrayBuffer现代浏览器将其置于隔离门控之后明确“哪些第三方资源可以加入页面”的信任边界同时带来更高的部署风险——如果未先审计资源、弹窗和嵌入启用即可能引发故障。快速参考Quick Reference规则技能文件给出了四条可直接执行的要点需要跨源隔离时同时使用Cross-Origin-Opener-Policy与Cross-Origin-Embedder-Policy在强制启用 COEP 之前审计每一个跨源 script、iframe、image、worker 和 font可嵌入资源按需使用 CORS 或Cross-Origin-Resource-Policy提供服务在依赖“仅限隔离环境”的特性之前先验证self.crossOriginIsolated true。核心头配置与运行时验证跨源隔离的标准头部组合是三组头各司其职文档响应携带 COOP COEP声明该文档希望与同源文档归组、并限制可嵌入的跨源资源Cross-Origin-Opener-Policy: same-origin Cross-Origin-Embedder-Policy: require-corp子资源响应携带 CORP表明该资源允许被哪些跨源文档引用Cross-Origin-Resource-Policy: same-origin在require-corp模式下页面下加载的每个跨源资源都必须通过 CORS 或 CORP 明确“加入”该页面。启用后应在浏览器中确认真的进入了隔离状态console.log(self.crossOriginIsolated)规则参考文档还给出了一个防御性的运行时常量检查模式适合用于依赖隔离特性的模块入口处if (!self.crossOriginIsolated) { console.warn(This page is not cross-origin isolated yet.) }这三个头的工作关系可以概括为COOP 决定“这份文档与谁隔离 opener 关系”COEP 决定“这份文档允许嵌入什么跨源内容”CORP 则站在资源一侧回答“这个资源允许被哪些文档使用”。三者组合后浏览器才会将顶层文档标记为 cross-origin isolatedcrossOriginIsolated才会为true。上线最佳实践1. 只在文档真正需要隔离时成对启用 COOP 与 COEP完整跨源隔离的常见模式就是上文的same-originrequire-corp组合启用后立刻用console.log(self.crossOriginIsolated)验证。只有看到true隔离才真正生效——头部出现在响应里不等于隔离生效。2. 先审计每一个跨源依赖COEP 改变了页面允许嵌入的内容范围。上线前需要逐项审查scripts第三方脚本、分析脚本fontsimagesiframesworkers分析工具与 tag-manager 类集成任何在 COEP 下加载的跨源资源都必须通过 CORS 或 CORP 主动声明兼容。这是“一个不兼容的第三方脚本就能毁掉整页”风险的主要来源。3. 谨慎处理弹窗流程OAuth、支付、客服等弹窗流程往往依赖 opener 关系。如果应用依赖这些行为必须在强制 COOP 之前显式测试这些流程并选择最窄的兼容设置。验收阈值与例外情况规则文档给出了明确的通过/失败判定标准这也是代码审查时可以落地的验收清单通过Pass预期路由返回兼容的 COOP 与 COEP 头且在需要隔离的位置self.crossOriginIsolated true。失败Fail应用依赖仅限隔离环境的 API但运行时实际并未进入跨源隔离状态强制头部组合下关键的弹窗或嵌入流程被破坏。同时规则也明确列出了应当不启用或谨慎启用的情形大多数站点不需要完整跨源隔离。只有当你真正需要这个安全边界或被门控的浏览器能力时才启用不要把它当作“时髦的默认项”如果只有应用的一小部分需要隔离特性路由级route-specific灰度比全局开启更安全某些第三方内容在 COEP 下就是无法工作。可能需要先替换或隔离该依赖再推进上线。验证方式自动化检查与人工检查规则将验证拆为两层且特别强调“隔离应由运行时行为如self.crossOriginIsolated来证明而不是只看响应头”。自动化检查检查代表性文档响应确认在预期位置存在 COOP 和 COEP检查关键子资源响应确认其提供了兼容的 CORS 或 CORP 行为。人工检查在浏览器中打开页面并检查self.crossOriginIsolated在预发环境中测试弹窗、OAuth、支付、分析与嵌入流程若应用依赖隔离专用 API 而self.crossOriginIsolated仍为false或关键第三方集成停止工作则判定上线失败。该规则在 Front-End-Checklist 仓库中的实现形态Front-End-Checklist 的核心设计是把检查清单同时服务于人类与 AI Agent。跨源隔离规则在仓库中呈现为三层结构理解这一结构有助于复用该规则到其他项目1. 规则源文件MDX规则的单一事实来源是 packages/content/rules/en/security/cross-origin-isolation.mdx。其 frontmatter 声明了categoriessecurity/javascript、subcategory: headers、priority、difficulty、estimatedTime以及供 Agent 使用的promptscheck/fix/explain/codeReview 四个动作的提示词与aiContext适用场景描述。这正是上文 Quick Reference 与“Check/Fix/Explain/Code Review”四段的来源。2. 生成的 Agent 技能Skills仓库通过 scripts/generate/generate-skills.ts 将每条规则 MDX 转换为skills/{slug}/目录SKILL.md承载 frontmatter 摘要与四段式提示词references/rule.md承载完整规则正文。从源码结构看buildSkillMd()会把aiContext规范化为 “Use when …” 开头的描述以便 Agent 意图匹配并把 TL;DR 列表渲染为## Quick ReferencebuildReferencesMd()则通过stripMdxToMarkdown()把 MDX 正文转为纯 Markdown。也就是说skills/cross-origin-isolation/SKILL.md 与其 references/rule.md 是从 MDX 规则文件生成并同步维护的产物。3. 关联规则Related Rules规则 frontmatter 中的relatedRules声明了四条同域规则构成了完整的浏览器隔离审查面关联规则关联理由content-security-policy两者都是基于头部的浏览器加固措施都应通过真实响应验证来落地permissions-policy高能力浏览器特性应在任何跨源隔离上线时被刻意限制cross-origin-securityCORS、postMessage 与 opener 行为与 COOP/COEP/CORP 作用于同一信任边界x-frame-options嵌入策略与 opener 隔离是不同控制手段但属于同一次浏览器隔离审查小结跨源隔离是一条“安全收益明确、部署风险同样明确”的加固路线。Front-End-Checklist 给出的方法论可浓缩为四步判断是否需要处理敏感数据、需要 opener 隔离、依赖 SharedArrayBuffer 等门控能力→审计全部跨源依赖scripts/fonts/images/iframes/workers/分析集成→成对启用 COOP COEP 并让子资源以 CORS/CORP 显式兼容优先路由级灰度显式测试弹窗与 OAuth 流程→用self.crossOriginIsolated true而非响应头作为生效证据。仓库中该规则的 MDX 源文件、生成脚本与技能产物三者保持一致也为将这条检查项接入团队评审流程或 AI 审计流程提供了可直接参考的实现样本。【免费下载链接】Front-End-Checklist The essential checklist for modern web development, for humans and AI agents项目地址: https://gitcode.com/gh_mirrors/fr/Front-End-Checklist创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
