Connection Allowlists：第三方脚本的数据出口终于被焊死了

每次接了一个第三方 SDK，你都不知道它把数据发去了哪里——这个困扰了你多少年的问题，今天被 Chrome 152 用一个 HTTP 头彻底隔开了。

事情是这样的

你接了一个数据分析 SDK，没问题。你接了一个监控 SDK，没问题。你接了一个 AI 编程工具的浏览器扩展——它现在能读你打开的任何页面，能把数据发到任何地方，你不知道，你管不了。

这不只是理论风险。npm 生态每天都在发生供应链攻击，一个被污染的包版本更新后悄悄加了数据外发逻辑，你跑 CI 的时候，你的凭证和用户数据就不知道去了谁手里。GitHub Actions 里跑着的第三方 action 也是同样问题——你给了它代码仓库的读写权限，它顺便把环境变量里存的 API Key 打包发了出去。

Chrome 152 今天把这件事在网络层焊死了。

Connection-Allowlist：服务器声明谁可以被访问

Connection-Allowlist 是一个 HTTP 响应头，服务器用它声明「这个页面只能访问以下这些端点」，浏览器在网络层直接拦截所有不在白名单里的请求——不是在 JavaScript 里做检查，是网络层直接阻断，连发出请求的机会都不给。

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

URL 模式支持通配符：*./ 匹配子域名，:*/ 匹配任意端口。也可以用报告模式，只记录不阻断：

Connection-Allowlist: (response-origin
  "https://cdn.example.com"
  "https://api.example.com"
); report-to=/csp-report-endpoint

支持的端点类型覆盖了 fetch、WebSocket、重定向、preload、DNS 预取、WebRTC、WebTransport——基本上涵盖了所有能从浏览器发出的网络请求。Service Worker 也受约束。

三个真实场景用得上的地方

场景一：npm 包供应链攻击
你锁了 package.json，但没锁运行时。一个被污染的 SDK 更新后悄悄加了一次 POST 把你的用户 ID 发去了境外服务器。有了 Connection-Allowlist，那次请求直接被浏览器在网络层拒绝，根本没有机会发出。

场景二：CI 环境里的第三方 action
你的 GitHub Actions workflow 跑了一个第三方 action，它拿到了 runner 的 GITHUB_TOKEN 读写权限——这是正常的——但它还尝试往非授权的端点发环境变量，这就不正常了。Connection-Allowlist 在这种场景下相当于给网络请求加了白名单，第三方 action 即使被攻陷，理论上也无法完成数据外发。

场景三：浏览器扩展和 AI 编程工具
Claude Code 浏览器扩展、Cursor 的远程服务连接——这类工具的远端地址是固定的，用 Connection-Allowlist 锁住之后，即使页面被 XSS 注入，攻击脚本也无法把数据发送到攻击者服务器。浏览器变成了你的防线，而不是漏洞。

三个坑你需要知道

第一个坑是 Safari 和 Firefox 暂时不支持，目前只有 Chromium 浏览器（Chrome/Edge 152+）生效。你需要配合 CSP 的 upgrade-insecure-requests 或 fetch-src 做降级，别把 Connection-Allowlist 当唯一防线。

第二个坑是 report-to 端点本身也不能在白名单之外，否则违规报告本身发不出去。声明白名单的时候记得把报告端点也加进去。

第三个坑是通配符作用域：*./example.com 不包含 example.com 本身，如果你同时需要主域名和子域名，要分别声明。另外 :tld 这种语法在当前版本里暂不支持，绑定具体域名是最稳妥的写法。

三步开始用

第一步：审计你的页面实际需要访问哪些域名。
打开 Chrome DevTools → Network，勾选 “All” 过滤器，正常操作你的应用，把所有发出去的请求域名整理出来。这个列表就是你的白名单初版。

第二步：加 HTTP 头，先用报告模式跑。

Connection-Allowlist: (response-origin
  "https://your-cdn.com"
  "https://your-api.com"
); report-to=/connection-allowlist-report

加完头之后到 Network 面板观察是否有违规请求被阻断，把漏网的域名加进去，逐步收紧。

第三步：切到强制模式。

Connection-Allowlist: (response-origin
  "https://your-cdn.com"
  "https://your-api.com"
  "https://your-analytics.com"
)

报告模式跑通之后再切，不要直接在生产环境开强制阻断——可能有测试环境漏掉的第三方脚本。

CSP 的继任者？

Connection-Allowlist 不是来替代 Content Security Policy 的。CSP 语法复杂、覆盖面广、配置门槛高，大多数团队只配了一条 default-src self 就躺平了。Connection-Allowlist 语法更简单，聚焦在一个具体问题上：我的页面只能发请求到这些地方，其他的免谈。

你可以把 Connection-Allowlist 理解为 CSP 的「最小化可行版本」——只解决数据外发这一件事，用法直观，配置容易，恰好够用。

现在 Chrome 152 已经稳定，这个能力已经在生产可用。下一个问题是：你接的每一个第三方 SDK，你真的知道它们会把数据发去哪里吗？