Chrome 终于能管住你的请求去哪了——Connection Allowlists 把这件事从根本变了

Chrome 终于能管住你的请求去哪了——Connection Allowlists 把这件事从根本变了

你配了 CSP，恶意脚本加载不进来——但它跑起来之后呢？

这是很多安全团队没有认真想过的问题。CSP 能拦的是「什么代码能进来」，但代码进来之后它向哪里发请求，CSP 原则上就管不着了。

这就是 Connection Allowlists 要填的坑。

简单说：服务器通过 HTTP 响应头声明允许的端点，Chrome 会在连接建立之前验证目标地址。未经授权的请求，浏览器直接在网络层拒绝。

配法大概是这个样子：

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

浏览器在请求发出去之前，会对照这份名单检查目标地址。不在名单里的 fetch、WebSocket、重定向、DNS 预解析、WebTransport、WebRTC，全部拦截。

这个功能解决的根本问题是：恶意代码拿到了代码执行权之后，依然无法把数据送到未授权的地方。即使绕过了一切应用层检查，网络层也过不去。

对金融、医疗、企业 SaaS 这些处理敏感数据的场景，这直接意味着：即使攻击者通过 XSS 或第三方漏洞拿到了代码执行权限，数据也送不出去。

Chrome 152 在 8 月 25 日稳定版发布。除了直接的防护价值，它还强制团队做一件早就该做的事：盘点自己到底在和哪些外部端点通信。上了允许名单之后，任何新增的第三方依赖、任何偷偷多发请求的 SDK，都会变成可发现的异常，而不是埋在暗处的盲区。

Teams 可以先用 Report-Only 模式跑一段时间，观察哪些请求会被拦截，再逐步建立允许名单：

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

Report-Only 模式会记录违规但不会阻断，给了团队足够的缓冲来迭代名单而不影响生产流量。

目前阶段有两个限制需要了解。一是它需要服务器端配合配置 HTTP 响应头，纯前端 SPA 如果没有后端配合是用不了的。二是目前仅文档上下文支持，Service Worker、Shared Worker 和专用 Worker 暂不在范围内。

但大方向是明确的：Chrome 152 是这个机制从实验进入生产的第一步，随着 W3C 标准化推进，其他浏览器跟进只是时间问题。

对于任何正在做 Web 应用安全规划的前端工程师或 DevOps 团队，这是今年最值得加入防御矩阵的 HTTP 头之一。CSP 守住了入口，Connection Allowlists 守住了出口——这两层加起来，才是真正意义上的浏览器侧网络边界控制。

下一步：打开 Chrome 稳定版，在 HTTP 响应头里加一行，先用 Report-Only 模式跑一周，看看自己的页面到底在和多少个端点通信。你可能会发现一些从来没注意过的第三方请求。