浏览器会让你的前端请求“听话”了——Chrome 152 Connection Allowlists 把这件事彻底变了

浏览器会让你的前端请求“听话”了——Chrome 152 新出的 Connection Allowlists 本质上是给页面加了一道浏览器级出口白名单。

以前你管前端网络，基本靠三层：CSP 的 connect-src、网关层的域名校验、以及代码里自己写的请求拦截。问题也很明显：CSP 语法重， gateway 看不到路径，代码拦截容易被 bypass。Chrome 152 这次直接把这道防线下沉到了网络层。

Connection Allowlists 的工作方式很直接：服务器通过响应头把允许访问的端点列表下发给浏览器，浏览器在建立任何连接之前先做一次校验，不在白名单里的请求直接在网络层被掐掉，不管这个请求是 fetch、WebSocket、WebTransport、DNS prefetch 还是 preload。

举个例子，服务器返回这样的头：

Connection-Allowlist: (“https://api.example.com/*” response-origin)

这意味着页面只能往 api.example.com 发请求，其他域名一律被拦截。如果你想先监控再强制执行，可以用报告模式：

Connection-Allowlist-Report-Only: (“https://api.example.com/*”); report-to=security-endpoint

这里有两个关键细节：一是重定向默认是被拦截的，你需要显式加 redirects=allow；二是 WebRTC 默认也是被拦截的，需要显式加 webrtc=allow。这两个默认值很合理，因为重定向和 WebRTC 都是动态端点发现，最容易成为数据外泄的盲区。

和 CSP 的 connect-src 相比，Connection Allowlists 的优势在于“一把梭”：它覆盖了所有出站连接类型，不需要你为每种 API 单独写 directive，也不需要处理 unsafe-eval 这种历史包袱。两者不是替代关系，CSP 管“什么能进来”，Connection Allowlists 管“什么能出去”，配合使用才是完整方案。

最值得关注的应用场景是 AI 编程工具和沙箱环境。AI coding agent（Claude Code、Cursor、Cline）在运行时经常需要访问外部 API、下载依赖、或者执行用户代码，这些操作如果没有出口控制，很容易成为数据外泄的通道。Connection Allowlists 让你可以在浏览器层面限制 AI agent 只能访问白名单内的端点，而不需要修改 agent 本身的代码。

渐进式落地的推荐路径是：先用 Report-Only 模式跑一周，收集实际出站请求，清理掉不必要的第三方调用，然后按域名切到强制模式。CI 里可以加一步：扫描构建产物里的硬编码 URL，和允许列表做 diff，有异常就卡发布。

这件事的意义不在于又多了一个安全特性，而在于浏览器终于开始把“网络边界”当成一等公民来做了。以前你要做出口控制，得在网关、CDN、代码三层分别做，现在浏览器原生支持，意味着单页应用和 PWA 也能拥有和原生 app 同等级别的网络管控能力。

现在 Chrome 152 已经稳定版发布，Firefox 和 Safari 的态度还在观察中。如果你在做 AI 编程工具、在线 IDE、或者任何需要加载第三方内容的平台，值得现在就试试。