你以为 CSP 已经够安全了？今天 Chrome 152 把 Connection Allowlists 放出来了，浏览器自己会拦

你配了三年 Web 安全，把 CSP 配得严严实实——script-src 只有自己域，object-src ‘none’，frame-ancestors 也限死了。然后你的页面里有一个第三方客服脚本，一个数据分析 SDK，一个 AI 补全的 JS 文件。它们执行的时候，fetch() 调用的接口、CSS 加载的背景图、WebSocket 建立的那个长连接——CSP 管得了吗？

管不了。CSP 的核心是「这个页面可以加载哪些资源」，不是「这个页面可以往哪里发请求」。数据从哪出去这件事，CSP 从来没有真正回答过。

Chrome 152（2026-08-25 正式发布）把这件事补上了。Connection Allowlists 是一行 HTTP 响应头，浏览器在网络层强制执行——不是你代码里写的那层防，是浏览器自己在连接建立之前就把门焊死。

一个典型配置长这样：

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

这行头的意思是：当前页面只能往自己的域和这两个白名单地址发请求，其他一盖拒绝。fetch()、WebSocket、redirect、fetch() 附带的那个 DNS 预取，全在管控范围内。哪怕页面里跑的是一段恶意 JS，哪怕它绕过了你应用层的所有检查，只要目的地不在白名单里，浏览器直接 RST 这个连接。

为什么说是「网络层」而不是「应用层」？因为你用 CSP 也勉强能做类似的事——用 connect-src 限制 fetch 的目标地址。但 CSP 的语法是为很多种控制目的设计的，connect-src 只是其中一个子集。你写 CSP 的时候其实在同时管 script-src、style-src、img-src、frame-src……这些能力混在一起，维护起来的复杂度早就超出了一行头的本意。而且 CSP 还有绕过记录，strict-dynamic、hash/nonce 的配合稍有不慎就有漏洞。

Connection Allowlists 只问一个问题：这个页面可以往哪些地方发网络请求？问得小，答得清。一条 Policy 声明完，不用跟其他安全能力抢语法空间。

和 CSP 的具体区别：

上线路径也给你留好了。先用 Report-Only 模式观察：

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

这个模式下 Chrome 会报告违规请求但不实际拦截。等你的监控系统收到足够多「本来应该被拦但现在只报了警」的记录，确认没有误报，再把 Report-Only 去掉，真实生效。

适用场景最清晰的是三类：

第一，页面里跑不可控代码。 AI 补全、第三方 SDK、沙箱编辑器、用户上传的 HTML——这些场景里你无法保证 JS 的行为干净。Connection Allowlists 让浏览器帮你兜底，数据发不出去就是发不出去。

第二，防止被入侵后横向移动。 如果一个 XSS 漏洞已经拿到了执行权限，攻击者的第一个动作往往是往自己的服务器发窃取到的 cookie 或 localStorage。配上 Connection Allowlists，这一跳在网络层就被断了。

第三，配合 CSP 使用形成纵深。 CSP 继续管「页面可以跑谁给的代码」，Allowlists 管「这些代码运行时可以去哪里」，两套机制各管一段。CSP 漏了，Allowlists 兜底；Allowlists 没配，CSP 还能拦住一部分。

Chrome 152 带来了两个配套能力值得注意：CPU Performance API 让浏览器告诉你的应用「用户这台设备是几线」，Connection Allowlists 让浏览器帮你管住「应用里的代码能访问哪些网络地址」。一个向下探测硬件，一个向外探测网络——2026 年的浏览器在安全这件事上终于开始从「防君子」往「防小人」方向落地了。

五天内就可以开始实测：在你现有项目的 Nginx/Apache/Caddy 配置里加一行 Response Header，用 Report-Only 模式跑一周，看控制台里有没有意外请求。如果没有，说明你的架构比想象中干净；如果有，那就正好是 Connection Allowlists 替你提前发现的。