service worker 不能直接过滤第三方脚本入侵，但可通过 fetch 事件拦截恶意脚本网络请求，实现间接阻断；它无法防御内联脚本、事件处理器、javascript:协议及xss注入等场景，必须与csp协同防护。
service worker 本身不能直接“过滤第三方脚本入侵”，它不扫描或拦截已注入页面的 `<script>` 标签，也不阻止 html 解析阶段的脚本执行。但它能在资源加载和网络请求层面施加精细控制，从而**间接阻断恶意第三方脚本的加载与运行条件**——前提是这些脚本依赖网络请求、未内联、且未被 csp 兜底放行。</script>
Service Worker 能做什么：拦截与重写请求
SW 在 fetch 事件中可捕获所有同源（及部分跨域）资源请求，包括 JS 文件。这意味着：
- 可以检查请求 URL 是否匹配已知恶意域名（如 cdn[.]evil-ad.net、tracker[.]badjs.com）并主动返回空响应或 404
- 可重写脚本响应内容，例如注入检测逻辑、剥离 eval 或动态执行代码段（需谨慎，可能破坏合法功能）
- 能缓存白名单内的第三方脚本（如 jQuery CDN），同时拒绝非白名单来源的同类请求
- 对通过 `importScripts()` 加载的子脚本同样生效，形成链式防护
但它不能替代 CSP：关键边界必须清楚
以下情况 SW 完全无能为力，必须靠 Content Security Policy（CSP）兜底：
- 内联脚本（
<script>alert(1)</script>）——SW 不介入 DOM 解析过程 - 事件处理器中的 JS（
<button onclick="malicious()"></button>） - 通过 `javascript:` 协议触发的执行
- 由 XSS 漏洞注入的脚本（如存储型 XSS 写入评论区）——此时脚本已存在于 HTML 中，SW 注册前就已执行
因此，仅靠 SW 做“过滤”是脆弱的。真实防护必须配合 CSP 的 script-src 指令，例如：Content-Security-Policy: script-src 'self' https://cdn.example.com; object-src 'none'; base-uri 'self';
实战建议：SW + CSP 协同防御模式
把 SW 当作“网络层守门人”，CSP 当作“执行层防火墙”，两者分工明确：
- 在 SW 的
fetch事件中，对所有request.destination === 'script'的请求做域名白名单校验，非授权源直接return new Response('', { status: 403 }) - 避免在 SW 中动态拼接或
eval()任何远程脚本内容，防止自身被绕过 - 确保 SW 脚本本身通过 HTTPS 加载，且服务端返回
Content-Type: application/javascript，否则注册失败 - 配合 CSP 的
worker-src 'self'，禁止从外部加载 Service Worker，堵住 SW 被替换成恶意版本的路径
警惕常见误区
有人尝试用 SW 动态 patch 页面中的 document.write 或重写 Function.prototype.constructor 来防 XSS —— 这类操作不仅不可靠（XSS 可在 SW 安装前触发），还会显著拖慢首屏，且违反浏览器安全模型。真正的防线始终是：输入过滤、输出编码、CSP 严格策略、HTTPS 全站启用。
