浏览器、网络与安全 · KNOWLEDGE CHAPTER

K14

跨源通信与隔离

跨源安全不是一个开关，而是几道不同的门：脚本能读什么、资源能嵌入什么、窗口能连通什么、身份状态按什么分区。每道门都不等于服务端业务授权。

浏览器、网络与安全2 道章节练习5 道主练关联

核心模型

原理与机制

先区分请求发送与响应可读

源由协议、主机、端口组成，同源策略限制脚本跨源读取。CORS 让服务器声明哪些来源可读响应；安全列出的请求可能直接送到服务器，再由浏览器决定是否把响应交给脚本。其他请求先经过 OPTIONS 预检。因此控制台跨域失败可能意味着实际请求被挡，也可能意味着操作已完成但回执不可读。JSON POST 常触发预检，no-cors 得到的 opaque 响应不能当成读取任意接口的通道。

凭据与预检拥有各自规则

跨源携带 Cookie 通常要 credentials:include，服务端允许带凭据读取时须给精确来源与 Allow-Credentials；通配来源不满足该条件，且 Cookie 仍受 SameSite、范围与隐私策略约束。预检缓存独立于一般 HTTP 缓存，白名单撤销不保证旧页立即重新预检，实际接口必须继续做认证与权限校验。JavaScript 可读响应也不等于可读所有头，下载文件名等需明确 Expose-Headers，Set-Cookie 则不能因此暴露给前端。

跨源隔离改变资源和窗口拓扑

SharedArrayBuffer 等能力常要求安全上下文与跨源隔离，常见组合是 COOP:same-origin、COEP:require-corp，并检查 crossOriginIsolated。COOP 影响浏览上下文组，可能切断登录弹窗的 opener；COEP 要求相关跨源资源通过适当 CORS 或 CORP。迁移要盘点图片、脚本、iframe 及认证完整链路，而不是只加两个响应头。隔离成功仍需 Atomics 和数据协议保证共享内存一致性，无法兼容时提供无共享内存方案。

分区与消息协议都要落回身份验证

Partitioned Cookie 增加顶层站点等分区维度，同一嵌入来源在两个不同站点可有独立会话；它不是按租户 ID 分区，也不会恢复跨所有网站共享登录。iframe 通信用 postMessage 时，发送端精确指定 targetOrigin，接收端同时检查 origin、预期 source、结构、版本及请求 ID。窗口引用可能在导航后指向别的文档，来源检查不能省略。支付等消息只作为重新查询的提示，真实结果仍向己方服务端核验。 Partitioned 要求 Secure，跨站发送还需适当 SameSite 配置并受浏览器策略约束；只加分区属性不保证会话可用。

把策略部署为可审计的通信契约

动态返回允许来源时，普通响应缓存也要正确区分 Origin，避免把合作方 A 的响应头缓存给 B。带凭据响应中的 Expose-Headers:* 不能当任意头的通配开放。沙箱 iframe 还应最小化脚本、表单与弹窗权限；同源内容同时开放 scripts 和 same-origin 可能削弱隔离。对 null 等不透明来源需要专门设计，不能因为精确白名单不方便就把它列为可信来源。每条消息都重新校验，握手一次并不提供永久信任。

最小示例

javascript

const expectedOrigin = 'https://widget.example';
const frame = document.querySelector('#widget');
const requestId = crypto.randomUUID();
function receive(event) {
  if (event.origin !== expectedOrigin ||
      event.source !== frame.contentWindow) return;
  const m = event.data;
  if (!m || m.type !== 'ready' || m.version !== 1 ||
      m.requestId !== requestId) return;
  console.log('当前 iframe 的当前请求已就绪');
}
window.addEventListener('message', receive);
frame.addEventListener('load', () => {
  frame.contentWindow.postMessage(
    { type: 'init', version: 1, requestId }, expectedOrigin);
}, { once: true });
// 页面/组件结束时移除 receive；每次新会话生成新 requestId。

示意要求代码在 iframe 首次 load 之前注册，子页面按约定回复 ready。错误来源、另一窗口和旧请求消息均被忽略。即使校验通过也只获得协议就绪信息，不由一条消息授予账户操作权限；嵌入文档导航或重建时应建立新会话。

环境：现代浏览器；页面已存在 id=widget 的 iframe，监听代码须在其首次 load 前注册，子页面实现相同握手协议。域名为示例。

核验：已静态审查示例与本章机制一致；未运行此示例，未进行框架或浏览器集成测试。观察结果为待复现的教学预期。

边界与取舍

边界

CORS 失败不是“服务器一定没收到”；预检通过也不是客户端持有授权证明。
同站不等于同源；不同子域可能共享站点分区，但业务租户仍必须独立校验。
COOP/COEP 收紧隔离，不解除同源策略；需要 opener 的登录弹窗可能因此失效。

取舍

较长预检缓存减少往返，却让部署策略收敛更慢；敏感权限撤销必须即时作用于业务接口。
独立来源与严格 sandbox 减少嵌入风险，但限制共享状态与交互能力，应只开放所需协议。

口述示范

我会把 CORS、跨源隔离和分区 Cookie 分开解释，再画出请求、凭据和消息的实际路线。关键判断是浏览器允许发送、允许读取与服务器允许操作三个问题；任何一层配置成功都不能替代另外两层。

章节练习

练习 1

合作方写权限被撤销，旧页仍发送成功的 OPTIONS 缓存请求。如何验收撤权？

展开检查点

保留旧页与预检缓存测试实际写请求。
服务器按身份和租户拒绝，数据不发生变化。
同时用非浏览器客户端验证，证明不依赖 CORS。

白板开启共享内存后登录失效，嵌入客服又在两站显示不同会话。分别解释。