Cloudflare Workers 兼容性标志 strip_authorization_on_cross_origin_redirect：跨源重定向时的 Authorization 头处理
【免费下载链接】cloudflare-docsCloudflare’s documentation项目地址: https://gitcode.com/GitHub_Trending/cl/cloudflare-docs
跨源重定向时是否自动携带Authorization头，是影响凭据安全与鉴权链路正确性的关键行为。Cloudflare Workers 通过strip_authorization_on_cross_origin_redirect兼容性标志，将这一行为对齐到 2022 年更新的 Fetch API 规范，并提供了retain_authorization_on_cross_origin_redirect反向标志以保留旧行为。读完本文，你将完整掌握该标志的触发场景、安全权衡，以及通过 Wrangler 配置、Cloudflare Dashboard 与 API 三种方式启用/禁用它的具体操作方法。
标志是什么
该标志定义于本仓库的兼容性标志清单中：strip-authorization-on-cross-origin-redirect.md。其元信息如下：
| 字段 | 值 |
|---|---|
| 标志名称（enable_flag） | strip_authorization_on_cross_origin_redirect |
| 反向标志（disable_flag） | retain_authorization_on_cross_origin_redirect |
| 默认启用日期（enable_date） | 2025-09-01 |
启用strip_authorization_on_cross_origin_redirect后，Workers 运行时在跟随一个跳转到不同源（origin）的重定向时，会自动从请求中移除Authorization头。这里的"不同源"指的是协议、主机名或端口任一不同的目标地址；而同源重定向不受影响，Authorization头会照常携带。
为什么需要这个标志：Fetch 规范的历史变迁
该行为并非 Cloudflare 的发明，而是当前 Fetch API 规范 的明确要求。规范要求浏览器与运行时在跨源重定向时剥离Authorization头，以防止凭据被意外发送到不属于用户原始信任域的服务器。
关键在于时间线：这一要求在 2022 年才被加入 Fetch 规范，而 Cloudflare Workers 在此前就已经实现了自己的 fetch 处理逻辑，并未包含该要求。因此：
- 按旧行为运行的 Workers，跨源重定向时会继续携带
Authorization头； - 若直接修改运行时行为，会让所有已部署、且可能依赖旧行为的 Worker 发生破坏性变化。
这正是兼容性标志机制的典型应用场景。根据本仓库的兼容性日期文档，Cloudflare 定期更新 Workers 运行时，但任何更新都不应导致已部署的 Worker 停止工作；对于可能存在向后不兼容的变更，通过compatibility_date与compatibility_flags让新 Worker 选择接入、旧 Worker 保持原状。strip_authorization_on_cross_origin_redirect正是这种"运行时缺陷修复 + 兼容性门控"模式的实例。
新行为与旧行为：安全性与适用场景的权衡
新行为：默认剥离，防止凭据泄漏
当标志启用（即对齐 Fetch 规范）后，跨源重定向请求将不再携带Authorization头。这消除了一个潜在的安全隐患：旧行为在重定向到不受信任的源时，可能导致凭据被意外泄漏。例如，你的 Worker 调用某个 API，该 API 返回 3xx 重定向到攻击者可控的主机，旧行为会带着Authorization头跟随跳转，从而把令牌交给恶意端点。
旧行为：并非天生不安全，某些场景下反而合理
原文档明确指出，旧行为并非天生不安全，在某些场景下甚至是期望的行为。典型例子：
某个需要鉴权的 API 希望重定向到新的主机名，同时让客户端继续携带它的凭据（credentials）完成后续请求。
在这种场景下，新行为会导致重定向后的请求不再自动携带凭据，从而破坏鉴权链路——客户端必须在收到重定向后手动重新附加Authorization头，或改用其他鉴权传递机制。
因此选择哪个行为，本质是安全默认值与兼容性/便捷性之间的权衡：
| 行为 | 优点 | 风险 |
|---|---|---|
| 剥离（新，Fetch 规范） | 跨源重定向不会意外泄漏凭据，符合 Web 平台标准 | 依赖旧行为的重定向鉴权链路会失效 |
| 保留（旧） | 跨源重定向可自动延续凭据，鉴权体验顺畅 | 重定向到不受信任源时存在凭据泄漏风险 |
如何配置该标志
兼容性标志有统一的配置入口。根据兼容性标志文档，共有三种方式。
方式一：通过 Wrangler 配置文件（推荐）
在 Worker 的 Wrangler 配置文件中声明compatibility_flags数组。以下示例显式开启strip_authorization_on_cross_origin_redirect：
{ "compatibility_date": "2025-06-02", "compatibility_flags": [ "strip_authorization_on_cross_origin_redirect" ] }如果想要保留旧行为（即使compatibility_date已经越过 2025-09-01），则使用反向标志：
{ "compatibility_date": "2025-10-01", "compatibility_flags": [ "retain_authorization_on_cross_origin_redirect" ] }本仓库自身的 Worker 配置可作参照：wrangler.jsonc 中声明了"compatibility_date": "2025-06-02"并使用了"compatibility_flags": ["nodejs_compat"]，展示了这一数组结构的实际写法。修改配置后，运行npx wrangler deploy使新配置生效。
需要说明的是：由于该标志的默认启用日期是2025-09-01，只要你的compatibility_date等于或晚于该日期，strip_authorization_on_cross_origin_redirect即默认开启，无需显式声明；显式声明反而可以让行为更可读。而compatibility_flags的作用有两个方向——既能提前开启尚未默认生效的变更，也能禁用过去已经变成默认行为的变更（这正是retain_authorization_on_cross_origin_redirect的用途）。
方式二：通过 Cloudflare Dashboard
登录 Cloudflare Dashboard，在对应 Worker 的Settings（设置）中找到 Workers 兼容性配置区域，即可修改compatibility_date与compatibility_flags。通过 Dashboard 创建的 Worker 会自动将兼容性日期设置为当前日期。
方式三：通过 Cloudflare API
通过 Workers Script API 或 Workers Versions API 上传 Worker 时，在请求体的metadata字段中携带compatibility_date与compatibility_flags：
{ "metadata": { "compatibility_date": "2025-10-01", "compatibility_flags": [ "retain_authorization_on_cross_origin_redirect" ] } }注意：通过 API 上传且未指定兼容性日期时，会回退到最早、即任何标志生效之前的兼容性日期（2021-11-02）。新建 Worker 时强烈建议在 API 上传中显式设置当前日期，以便尽早获得规范行为与安全修复。
源码层面的佐证与仓库上下文
本文所述机制在本仓库中有多处相互印证的依据：
- 标志本体定义于 src/content/compatibility-flags/strip-authorization-on-cross-origin-redirect.md，其 frontmatter 记录了
enable_flag、disable_flag与enable_date等元信息，这是兼容性标志清单的标准格式（仓库中共有 125 个此类文件）； - 兼容性机制的总体原理见 src/content/docs/workers/configuration/compatibility-dates.mdx：兼容性日期用于一次性接入截至该日期的全部标志，且旧日期会被永久支持；
- 标志配置的三种入口见 src/content/docs/workers/configuration/compatibility-flags.mdx；
- 仓库实际使用的配置样例见 wrangler.jsonc。
注意：兼容性标志目录下这些文件的 frontmatter 中设置了publishResources: false、render: never、list: never，即它们作为结构化数据源被消费，而非独立渲染的页面——实际面向开发者的综合说明位于compatibility-dates与compatibility-flags两个文档中。这也解释了为何在"标志清单"与"综合说明"两处都能看到该机制的内容。
升级到新行为前的检查清单
由于strip_authorization_on_cross_origin_redirect会在兼容性日期达到2025-09-01后默认生效，升级compatibility_date前请对照检查：
- 审查重定向链路：梳理 Worker 中所有
fetch()调用，确认是否存在"API 重定向到新主机并要求延续凭据"的模式。若存在，需要改为手动处理：捕获重定向响应后，在后续请求中显式设置Authorization头； - 确认目标源可信度：对每个跨源重定向目标，评估"自动携带凭据"是否必要。若目标不受信任或不可控，保留新行为（剥离）反而是更安全的选择；
- 选择保留旧行为：如果确实依赖旧行为且无法改造代码，在
compatibility_flags中显式加入retain_authorization_on_cross_origin_redirect，并记录该例外，避免后续误删； - 部署后验证：运行
npx wrangler deploy后，对重定向场景做端到端测试，确认Authorization头的携带/剥离符合预期。
总结
strip_authorization_on_cross_origin_redirect是 Cloudflare Workers 对齐 Fetch 规范、消除跨源重定向凭据泄漏风险的关键兼容性标志。它默认在2025-09-01起生效，并可通过retain_authorization_on_cross_origin_redirect反向保留旧行为。理解"规范要求"与"历史实现"的差距，结合自身重定向鉴权链路的具体形态做出选择，是安全升级compatibility_date的前提。
【免费下载链接】cloudflare-docsCloudflare’s documentation项目地址: https://gitcode.com/GitHub_Trending/cl/cloudflare-docs
创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
