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_flagstrip_authorization_on_cross_origin_redirect反向标志disable_flagretain_authorization_on_cross_origin_redirect默认启用日期enable_date2025-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），仅供参考