Chrome 152 的 Connection Allowlists 怎么限制网页外连：从响应头到失败验证

如果一个页面加载了第三方脚本，脚本就可能尝试把数据发往不在业务清单里的域名。Chrome 152 带来的 Connection Allowlists，正是把这道检查前移到浏览器网络层：页面通过 Connection-Allowlist 响应头声明允许连接的 URL 模式，浏览器在连接建立前决定放行还是阻断。

它适合做“默认拒绝、按域名放行”的网络边界，但仍应和现有 CSP、服务端鉴权及日志监控一起使用；先在本地验证阻断结果，再考虑扩大到真实用户。

第三方脚本为什么需要浏览器级外连边界

传统做法通常是把允许访问的服务写在应用配置里，再在业务代码中判断 URL。但页面里的每个脚本、动态导入和 Web API 都可能发起网络动作；只在业务函数入口检查，容易漏掉重定向、WebSocket 或不经过统一请求封装的调用。

Chrome 官方把 Connection Allowlists 定义为文档或 Web Worker 的网络沙箱。对本轮文章关心的文档场景来说，关键变化不是新增一个请求库，而是让浏览器在连接建立前拿目标地址与 allowlist 比对。目标不匹配，请求在网络层就被挡住。

先落一个只允许业务 API 的最小配方

假设页面由 https://app.example.com 提供，业务接口位于 https://api.example.com。服务端先返回这一行响应头：

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

这里的两个元素各有职责：URL 模式只允许 API 域名下的路径，response-origin 则把页面本身的来源加入允许范围。这样页面仍能访问同源资源，第三方脚本却不能随意把请求改投到陌生域名。

Connection Allowlists 是响应头能力，不能用一个前端变量替代。实际部署时，确认反向代理没有丢掉该响应头，并把它放到真实页面文档的响应上，而不是只加在静态 JavaScript 文件上。

把允许和拒绝都走一遍，别只看响应头存在

本地验证时可以在 Chrome 地址栏打开 chrome://flags/#connection-allowlist 并启用开关，然后让开发服务器返回上面的响应头。接着打开 DevTools 的 Network 面板，分别触发一个 API 请求和一个指向未列入清单的测试请求。

1. 访问页面并在 Network 面板确认文档响应包含 Connection-Allowlist。
2. 点击页面上的正常查询按钮，确认 https://api.example.com/... 请求能够完成。
3. 触发指向未授权域名的请求，确认请求显示为 blocked:other 或连接错误；再到 Issues 面板查看是否有策略解析提示。

验收标准是“允许请求成功、越界请求在浏览器侧失败、策略拼写错误有可见提示”三件事同时成立。只看到接口返回 200，还不能证明边界生效，因为那可能只是请求根本没有走到你预期的响应头文档。

报告模式适合先摸清现有页面的真实外连

如果页面依赖还没有盘清，直接收紧可能把埋点、登录跳转或图片服务一起挡掉。官方提供 Connection-Allowlist-Report-Only 作为观察路径：先解析策略并发送违规报告，再根据报告收敛正式清单。

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

报告模式的意义是发现未知依赖，不是安全结果本身。等你核对完报告里的目标，再把明确需要的服务加入正式 Connection-Allowlist。对包含用户数据的页面，服务端鉴权、接口权限和敏感字段最小化仍然不能省。

它和 CSP 的分工不同，别拿一套配置包打天下

CSP 更关注资源从哪里加载、哪些脚本可以执行以及页面能否建立某类内容连接；Connection Allowlists 则把重点放在“所有网络连接的目标是否在清单里”。二者可能覆盖相近风险，但审计视角不同。

一个实用组合是：CSP 继续约束脚本和资源来源，Connection Allowlists 给页面外连设置更窄的网络边界，服务端再对每个 API 请求做身份和权限校验。这样某个脚本即使绕开了应用层请求封装，也不能自动获得一个新的外发目的地。

上线前检查这五个边界

• 确认清单覆盖的是实际 URL 模式，而不是只写了一个不会匹配请求路径的裸域名。
• 把同源页面、API、登录回调、上传和监控端点分开核对，避免一次性写成过宽的通配模式。
• 先用 Report-Only 观察现有依赖，再在灰度环境开启正式阻断。
• 保存 Network 中的允许与阻断证据，并关注 Issues 面板的解析错误。
• 保留 CSP、服务端鉴权和错误监控；Connection Allowlists 不是业务授权系统。

相关问题

Connection-Allowlist 能替代 CSP 吗？

不能。它主要限制网络连接目标，CSP 还承担脚本、资源和内容加载方面的约束，二者更适合互补。

为什么配置了响应头却没有阻断？

先确认响应头出现在文档响应上，再确认 Chrome 版本、实验开关或正式支持状态，以及请求是否真的由该文档发起。策略解析错误可在 Issues 面板继续查。

应该先写多少个允许域名？

从页面真实依赖出发逐个加入，先保留最小集合。无法解释用途的域名不要因为“以后可能用到”就直接放进正式清单。

把验证结果留在发布记录里

Connection Allowlists 的价值在于边界可见、失败可复查。把响应头、允许请求、越界请求和 Issues 结果一起记录，下一次依赖变更时就能知道是业务新增了外连，还是策略意外变宽。Chrome 152 的这项能力值得试，但生产上线仍应沿用原有安全机制，逐步灰度。