Connection Allowlists：Chrome 发布与适用边界

BotBrowser 没有宣称实现或启用 Connection-Allowlist，本文也没有 BotBrowser 测试结果。该提案通过响应头策略限制文档或 worker 发起的显式网络连接。Chrome 在 2026-09-23 发布的公告称 Chrome 152 引入该功能供测试；但 ChromeStatus 当前条目显示 “Missing feature”，且没有公告 URL。应把这视为有时间版本差异的证据：公告描述某一日期的发布说法，状态页是另一个时间点的快照，WICG 文本仍是设计草案，不代表你正在使用的浏览器已经执行此策略。

TL;DR

• Connection-Allowlist 是针对显式连接目标的响应头策略提案，不会取代 Content Security Policy 的全部作用。
• WICG 文档是 Community Group 草案；语法与示例属于设计材料，不是跨浏览器支持证据。
• Chrome 的 2026-09-23 公告称 Chrome 152 引入该功能用于测试；ChromeStatus 的功能 5175745573945344 当前显示 “Missing feature”。记录双方说法、日期与范围，不要合并成“已支持”。
• 策略归属于文档或 worker 上下文。嵌入内容的强制执行提案还增加父级要求和子级选择加入机制，不能从父页面响应头推断出来。
• BotBrowser 一般可重复执行经授权、上下文明确的浏览器流程，但本文没有声称它已实现或实测支持 Connection-Allowlist。应保留现有控制，并测试应用的预期失败状态。

目录

• 提案控制什么
• 如何解读发布证据
• 策略与上下文范围
• 规划安全测试
• 分类失败并选择回退
• BotBrowser 能力边界
• 实践结论

提案控制什么

WICG 提议由服务器随响应发送可接受目标列表。用户代理会在代表上下文建立显式连接之前检查目标。提案涉及 Fetch 以及平台其他连接路径，包括 WebRTC、WebTransport、FedCM、Web Payments、DNS prefetch 和导航。核心设计目标是广泛覆盖由该上下文发起的显式通信，而不是为不同资源类型分别配置一套指令。

提案中的示意响应头如下：

Connection-Allowlist: (response-origin "https://cdn.example" "https://api.example"); report-to=connection-policy

这是设计示例，并非可以直接复制到生产环境的操作指令。response-origin 表示提供响应的源；明确的 URL pattern 表示其他目标。提议的报告参数将违规情况关联到 Reporting API endpoint。具体语法、匹配规则、连接类型与报告行为，都必须以所审阅的规范版本和浏览器实现为准。

该列表不是通用内容完整性策略。WICG 威胁模型关注通信渠道，并指出该策略不能解决内容注入或跨站脚本。如果被注入的脚本能读取敏感页面数据，阻断部分出站连接或许能减少一种外传路径，但不会消除注入、阻止所有侧信道，也不能修复被篡改的响应头。它只是承诺范围有限的纵深防御一层。

这一区别也影响与 Content Security Policy 的比较。CSP 仍适用于资源来源、脚本等限制。WICG 的设计动机是：面向连接的规则可能比多个资源类型指令更整体地覆盖显式网络连接。这只是设计理由，不意味着 CSP 已过时，也不证明新响应头会与所有策略正确组合。目标浏览器对相关请求类型的实际行为未确认前，应保留现有控制。

提案处理的是目标地址，不是请求的业务含义。发往允许 API 的请求仍可能包含应用不应披露的数据。请求被阻止不能证明页面安全、没有其他渠道观察数据，也不能证明服务先前未收到相关操作。授权、用户同意、输入验证和服务端审计仍由原有责任方负责。

如何解读发布证据

Chrome 在 2026-09-23 发布的公告标题为 “Connection allowlists: Secure your web application's network access”。公告称 Chrome 152 引入 Connection Allowlists，并将其描述为限制页面网络访问的方式。这是有用的发布信息，但单凭公告无法确认所有请求路径、平台、默认启用状态、企业可用性或每种部署的最终里程碑。记录时应保留这些限定条件。

功能 5175745573945344 的 ChromeStatus 页面承担不同作用。它将功能命名为 “Connection Allowlists”，描述通过 HTTP 响应头发送授权目标列表，并称匹配目标将获准、其他目标会被阻止。当前 web_feature 字段为 “Missing feature”；各阶段记录没有公告 URL。如果把两处内容都理解为描述同一个当前版本状态，状态快照就与 Chrome 152 的公告措辞冲突。

不要默默选择更乐观的页面来消除矛盾。状态面板可能滞后、采用不同里程碑定义，或显示与产品公告不等价的检测字段。反过来，公告也可能描述实验、开发者测试或分阶段启用，不能证明某个已安装二进制文件具有相同表现。现有页面无法确定具体原因。因此更稳妥的结论是：公告报告 Chrome 152 引入测试；状态快照当前为 “Missing feature”；WICG 规范仍是草案；依赖强制执行前必须验证明确版本和发布渠道。

记录一个简洁的证据元组，而不是单一的支持布尔值：

证据项	记录内容	不要据此推断
公告	规范 URL、发布日期、Chrome 里程碑的原文	所有平台都已稳定支持
ChromeStatus	功能 ID、查看日期、可见状态与阶段字段	单个状态字段完整描述了产品实验
规范	版本或查看日期以及草案状态	看起来规范化的文本已在浏览器中发布
运行时检查	产品、完整版本、渠道、操作系统、响应与请求结果	一个测试覆盖所有 API 路径或未来版本

Chrome 的定日公告与实时 ChromeStatus 记录可能在不同时间更新。如果决策依赖它们，应保留带日期的内部记录。功能有 ChromeStatus 条目不代表它必定可用；但在公告称可测试时，也不应只凭一个状态字段就宣告不可用。隐私验证令牌提案也体现了 Chrome 提案状态与实际可用行为之间的区别。两者的冲突意味着需要明确决策适用范围。

策略与上下文范围

基础提案把策略放在创建文档或 worker 的响应中。问题不仅是“列表包含哪些域名”，还包括“哪个上下文收到哪项策略、策略来自哪个响应、哪个操作发起了连接”。不能假设某页面的策略会限制另一个拥有独立响应和策略容器的文档。WICG 讨论了一些本地 scheme 和创建上下文的继承，但具体规则应以相关草案和实现为准。

iframe 会带来另一个策略所有者。父页面限制自身连接，不代表跨源子页面采用相同响应策略。WICG 的嵌入执行说明提议，由嵌入方要求子页面采用 allowlist，子页面再通过同样严格或更严格的策略、明确响应头或继承状态的本地文档选择加入。该说明还提到要求向嵌套后代传递。这是仓库中独立的设计提案，不是已经普遍发布的 iframe 行为。

上下文或事件	评审问题	验证之前的保守预期
顶层文档	最终响应是否含预期策略？	保留 CSP 和服务端控制；源代码模板不能证明实际交付了头部。
Worker	哪个响应创建它，策略是继承还是单独声明？	用合成目标单独测试 worker 路径。
跨源 iframe	子页面是否接受父级要求，返回了什么响应？	观察到之前按独立边界处理。
嵌套 frame	要求是否继续传递且不能被放宽？	逐层测试，不从直接子级推断所有层级。
重定向响应	目标实现是否阻止该重定向？	单独记录结果，不为通过测试而添加宽泛例外。
用户发起的导航	这是该上下文发起的显式连接吗？	不假设页面响应头能约束浏览器或其他上下文。

“allowlist”这个名称容易让人误以为保证强于提案实际范围。上下文级策略取决于该版本覆盖的请求类型、适用上下文、实际交付的响应头，以及浏览器实现。如果产品依赖这些路径，就应为 worker、service worker、嵌套 frame、重定向、preconnect、WebRTC、WebTransport 与导航分别命名测试案例。

Connection-Allowlist 也不是代理配置。它表达应用侧的目标策略；代理在另一网络层转发流量，并有独立的路由和认证职责。企业浏览器网络边界图划分了浏览器、代理、企业网络和目标服务的责任。关于协议本身，HTTP 代理语义指南说明请求、CONNECT、DNS 与来源边界。Permissions Policy 指南则讨论浏览器能力授权；能力委派不等于决定上下文可以访问哪些网络目标。

规划安全测试

真实服务采用新强制策略之前，先定义一个由团队控制、使用合成数据的测试页面，以及一份简短的预期目标列表。让策略决策可观察，但不要记录账户标识、生产数据、凭据或用户浏览轨迹。使用团队控制的测试端点；不要为了证明拦截有效而发送敏感信息。

从两个案例开始。第一个向预期应匹配的目标发请求，第二个尝试列表之外的目标。使用本地或受控测试接收器，检查它是否收到请求。控制台消息和接收器结果回答的是不同问题。不要把预期拒绝与 DNS、TLS、CORS、超时或服务器错误混为一谈。

只为产品依赖的路径增加案例，例如 Fetch、图片或脚本资源、worker 请求、嵌套 frame，或 WebRTC/WebTransport 建连。WICG 提案希望覆盖多种显式连接机制，但测试集应来自应用真实调用路径和浏览器已记录的实现范围。无需建立用户网络目标清单；少量、目的明确且有责任人的合成案例足够。

评审记录可以使用稳定字段：

{
  "fixture": "connection-policy-smoke-v1",
  "browser": "声明产品、版本、渠道与操作系统",
  "context": "top-level-document",
  "policySource": "测试响应头版本",
  "case": "listed-endpoint",
  "expected": "受控测试接收器收到请求",
  "observed": "记录实际且有界的结果",
  "applicationFallback": "保留主要内容并提供重试",
  "dataClass": "synthetic"
}

这是字段形状示例，不是测试结果或 BotBrowser 运行记录。只有在真实且经授权的测试中才填写实际值。公开文章或长期保存的证据文件中，不要放入包含密钥的 URL、请求正文、cookie、账户 ID 或长期 profile 标识。浏览器版本与 fixture 修订号有用；完整用户轨迹没有必要。

确保三个层面都可观测。响应层检查重定向后的最终响应和确切策略头部。浏览器层记录预期请求路径及浏览器是否报告或阻止它。应用层断言界面显示预期状态且关键内容仍可使用。一个层面的通过不能代替其他层面：配置源中的头部不证明 CDN 交付了它，UI 标记也不证明网络请求被拦截。

为超时设界，并明确区分准备阶段失败。测试页面未加载是可用性错误。测试接收器不可达则说明没有观察到预期结果。浏览器不识别策略时，应标记为未验证，而不是把结果映射成“允许”。任意抛出的异常都不能当成成功阻断的证明。错误记录应保留原始阶段和原因。

只有当实现和规范明确提供报告或遥测模式、且其语义已经核实时，才使用该模式。不要自行发明观察头部，也不要因为示例出现 report-to 就认定其已生效。如果没有安全的观测模式，就从非生产环境的 fixture 和可逆计划开始。明确 allowlist 的审批责任人、条目的过期方式、关键依赖的恢复人和临时例外的复核流程。通配符会让验证失去意义。

分类失败并选择回退

观察到的结果	首先检查的负责人	安全的下一步
最终响应没有策略头部	源站、CDN 或部署配置	对比实际响应与测试版本；不要推断浏览器支持。
列出的目标未到达接收器	DNS、TLS、路由、服务器或 pattern	使用合成数据检查失败阶段及规范化目标。
未列出的目标到达接收器	实现、范围或覆盖问题	保存证据并注明版本、渠道、上下文和 API；不要把该构建作为控制。
列出的目标被阻止	语法、pattern、重定向行为或实现缺陷	每次只改一个变量复现；查明原因前不要扩大列表。
阻断后页面不可使用	应用回退及依赖负责人	恢复已知配置，或展示清晰的不可用状态。
子 frame 的表现不同于父页面	子页面响应和嵌入方要求	记录双方响应与选择加入状态，不要把父页面结果套用到子级。

第三方服务不可用与策略拒绝不是一回事。界面应说明资源不可用，保留页面其他部分，并在合适时提供明确的重试方式。不能仅因为请求失败就显示安全成功：超时可能代表网络故障，而不是 allowlist 作出的判定。

配置修改应配套回滚方案。保留最后一个已知可用的响应头和依赖清单，使负责人可以恢复关键目标，而不改动无关的安全控制。临时例外应注明目标、原因、负责人、到期时间和后续测试。不要把临时问题变成永久通配符，不要关闭 CSP，也不要删除拒绝断言来让构建变绿。

正确决定也可能是暂缓。如果浏览器版本未知、来源互相矛盾、关键 API 路径缺少证据，或应用回退会暴露敏感行为，就继续保留服务端授权与 CSP，把 Connection-Allowlist 标记为“尚未依赖”。设定停止条件：若合成的未列出目标到达接收器，就不能把该构建和上下文视为已接受的控制。

BotBrowser 能力边界

一般而言，BotBrowser 可以在声明的上下文中重复经授权的浏览器流程，并记录应用公开的结果。这不表示产品已经配置、解析、执行或报告 Connection-Allowlist。本文没有引用 BotBrowser 对此功能的实现文档或测试记录，也没有为本文运行 BotBrowser。上面的 fixture 结构不是产品命令、已支持选项或实测兼容结果。

如果团队以后在经授权的 BotBrowser 流程中评估此功能，应先确认准确的二进制文件、版本、平台、profile、启动条件、实际响应头和接收器结果。文档、worker 与 frame 案例应分开验证。运行环境若不执行响应头，形似策略的响应或应用报错都不能凭空产生支持。结果只能适用于受测构建和 fixture，并应保留安全回退。

BotBrowser 不能控制网站响应头，不能让 Chrome 实验在其他浏览器中生效，不能保证不同实现对目标采用相同匹配方式，不能认证网站安全，不能移除 XSS、阻止全部侧信道，也不能证明远程服务未从其他路径收到数据。它也无法让状态页与发布日期公告自动一致。这些是实现和证据边界，不是需要绕过的设置。

要审查更广泛的防护措施，可查看 Content Security Policy 指南，了解 CSP 的独立职责。应把两种机制视为可能互补，并在目标运行环境中核实实际组合行为，再考虑替换其中一种。

实践结论

Connection Allowlists 是一个有前景但范围明确的提案，用于控制文档或 worker 发起的显式连接；相关证据具有时间与上下文边界。2026-09-23 的 Chrome 公告称 Chrome 152 引入测试；ChromeStatus 当前对 5175745573945344 显示 “Missing feature”；WICG 规范仍为草案。应把三项事实并列记录，注明具体构建和策略范围，并在合成 fixture 验证需要的路径前不要依赖其执行效果。

安全的下一步是保留现有控制，建立由团队控制、检查两个目标且带清晰回退的测试，在修改生产头部前重新检查官方来源。一次受控测试只证明所声明的浏览器、上下文、响应和 fixture 产生了该结果；它不能证明普遍支持、完整阻止外传或 BotBrowser 支持。

若要补充了解信任信号与网络边界，可阅读 Private Verification Tokens：Chrome 提案与 BotBrowser 当前状态 和 企业浏览器网络边界：明确责任，避免遗漏。两篇文章分别讨论提案状态和各层责任，本文不将它们混为一谈。

来源

• Chrome: Connection allowlists: Secure your web application's network access (2026-09-23)
• ChromeStatus: Connection Allowlists, 功能 5175745573945344
• WICG: Connection Allowlists 规范
• WICG: Connection Allowlists 解释文档
• BotBrowser：高级功能

**实践结论：**保留现有控制，并在依赖该提案之前验证明确的构建版本和上下文。