你以为 fetch 安全只能靠 CSP？今天 Chrome 用一行响应头把这件事彻底原生化了

你以为 fetch 安全只能靠 CSP？今天 Chrome 用一行响应头把这件事彻底原生化了

做过敏感数据页面的前端工程师大概都踩过这个坑——页面上接了第三方脚本，你不知道它什么时候把用户数据往不该发的地方送。想控住这个出口，翻遍了 CSP 文档，发现它管的是”谁能加载什么脚本”，而不是”页面能往哪里发请求”。两个问题是相关的，但答案是两套逻辑。

Chrome 152 正式把 Connection-Allowlist 推到了稳定版。这个 HTTP 响应头做的事情很简单：让服务器声明”这个页面只能往这些地址发请求”，浏览器收到后主动拦截不在白名单里的外发连接。fetch、WebSocket、Beacon、导航请求，全部覆盖，没有例外。

具体怎么用？在服务器返回的 HTTP 头里加一行：

Connection-Allowlist: (response-origin "https://api.example.com/*" "https://cdn.example.com/*");

response-origin 关键字把当前页面自己的源也纳入白名单，开发者不需要重复声明。然后接两个具体的目标 URL pattern，支持通配符。

覆盖范围比想象的宽。Fetch API、WebSocket 构造、navigations、redirects、DNS prefetch、WebRTC、WebTransport、preload 连同 preload 扫描阶段的请求，全部受这个策略约束。相当于在网络层画了一条硬边界。

如果你想先看效果不想直接断掉，可以用 Report-Only 模式先跑：

Reporting-Endpoints: connection-allowlist="https://security.example.com/reports"
Connection-Allowlist-Report-Only: (response-origin "https://api.example.com/*");

浏览器照常放行所有请求，但把违规情况上报到你指定的 Reporting Endpoint。你可以在控制台的”问题”面板里看到具体哪次请求触发了违规，以及目标 URL 是什么。

这个头和 CSP 的区别值得说清楚。CSP 是一套复杂的策略语言，声明式地控制 script-src、frame-src、object-src 等多个维度，语法本身就需要专门学习，而且随着要控制的维度增多，策略文本会变得非常长。Connection-Allowlist 只问一个问题：这个页面能连哪些外部地址？ 答案写出来往往只有两行。在 Chrome 152 里它和 CSP 是互补关系，不替代 CSP。CSP 继续管”谁能在我这里执行代码”，Connection-Allowlist 管”我的代码能往外发给谁”。

实际的适用场景有两个值得关注。第一个是 AI 沙箱——如果你的产品允许用户提交 AI 代码或 prompt，代码最终会在浏览器里执行，fetch 调用完全受控于页面本身，在 Connection-Allowlist 模式下即使用户注入了恶意脚本，也没法把数据外发到你的日志服务或外部 API。第二个是 SaaS 隔离——把应用的核心功能部署在固定的后端域名下，用 Connection-Allowlist 硬编码白名单，即使第三方 SDK 或广告脚本被攻破，也不会成为数据泄露的跳板。

Chrome 152 以上的版本全部支持，Firefox 表态 Positive，Safari 还没给出信号。caniuse 当前覆盖率约 82%，主流设备已经能用。如果你的产品面向高安全需求场景，现在就可以在 report-only 模式下接上，观察两周再切强制模式。

下一步：第一步，打开 Chrome DevTools Network 面板，看一眼你的页面实际外发了哪些请求，把这些域名收集成白名单；第二步，在测试环境加 Connection-Allowlist-Report-Only 头，接入 Reporting API，看两周有没有意外触发的请求；第三步，把确认无误的 pattern 写入正式头，切掉 Report-Only。CSP 策略里已有的安全声明照旧保留，两个头各管各的，网络层多一道锁，心里踏实得多。