部分Windows用户Chrome扩展Fetch API异常带Origin标头致CORS错误

1. 部分Windows用户Chrome自动添加Origin: chrome-extension://<extension-id>的原因 #

• 核心是Chrome在Windows平台的扩展请求处理逻辑存在环境差异：
  • 若用户的Chrome受Google Workspace企业政策管控，管理员可能配置了强制跨源校验的规则，触发Origin标头自动注入。
  • 部分Windows第三方安全工具（杀毒、防火墙）会修改Chrome的网络栈，强制为扩展请求添加Origin以做安全校验。
  • Chrome的实验性flag #extension-origin-in-requests被意外开启（可能是用户误操作或企业推送），该flag会让扩展的fetch请求强制携带Origin标头。
  • Manifest V3的扩展在Windows某些环境下，Chrome的隔离策略更严格，默认给跨域请求加上Origin标头。

2. 能否强制Chrome不添加Origin标头？ #

没有绝对的强制禁用方法，但可以通过以下方式规避：

• 切换到后台脚本发起请求：扩展后台脚本的fetch请求默认不会带Origin标头，把内容脚本的请求逻辑移到后台，通过消息传递交互即可。
• 完善manifest权限配置：在manifest.json中明确声明目标API的域名权限（比如"https://your-api-domain.com/*"），Chrome会将这类请求视为扩展的“同源请求”，减少Origin注入。
• 修改fetch的mode参数：显式设置fetch(url, { mode: "no-cors" })，但这种模式下无法读取响应内容，仅适用于只需要发送请求、不需要处理返回的场景。
• 关闭实验性flag：让受影响用户打开chrome://flags/#extension-origin-in-requests，将选项设为Disabled后重启Chrome。

3. Google Workspace管理员是否能控制Origin标头的发送？ #

是的，管理员可以通过Chrome政策强制触发Origin标头：

• 管理员可通过ExtensionSettings政策，对指定扩展启用严格跨源校验规则，强制请求携带Origin。
• 另外，CORSAllowlist等相关政策也可能间接调整Chrome的跨域处理逻辑，导致Origin标头被自动添加。
• 用户可通过chrome://policy页面查看是否有相关企业政策被应用。

推荐修复方案 #

1. 服务器端适配：最彻底的解决方式是在服务器配置Access-Control-Allow-Origin，允许chrome-extension://<你的扩展ID>，如果接口允许公开访问，也可以用*。
2. 扩展架构优化：统一将API请求放在后台脚本处理，避免内容脚本直接发起跨域请求，从根源减少Origin问题。
3. 用户侧排查：指导受影响用户检查是否有企业政策、第三方安全软件干扰，或关闭对应的Chrome实验flag。

内容的提问来源于stack exchange，提问作者kv stack