Service Worker不能主动识别非法篡改，仅程序化控制请求响应流程；其fetch事件仅拦截同源或合法跨域的页面主动请求，且必须依托HTTPS与可信元数据（如Content-Digest头）实现哈希校验闭环，失败时应上报、降级或透传原始响应，严禁静默替换。

service worker 本身不能“强制拦截非法篡改请求”——它不检测“非法”或“篡改”，也不具备主动识别攻击的能力。它的作用是**程序化地控制已发起的请求与响应流程**，安全防线必须由开发者基于可信元数据、确定性校验和明确策略来构筑。关键不在“拦截动作”，而在“拦截后做什么”。

哪些请求能被真正拦截并可控处理

Service Worker 的 fetch 事件只对满足以下全部条件的请求生效：

• 由当前受控页面主动发起（如 fetch()、XMLHttpRequest、、<script></script>、 等）
• 同源，或跨域但响应头含有效 Access-Control-Allow-Origin
• 非导航主文档请求（除非注册时 scope 显式覆盖且页面匹配）
• 非 sendBeacon()、非 内部资源、非 SW 自身安装请求

拦截后实现完整性校验的关键步骤

哈希校验不是开关式操作，而是需闭环执行的三步链路：

• 可信哈希源：不能硬编码在 sw.js 中。推荐服务端随资源返回 Content-Digest 头（RFC 9530），或为每个文件提供同名 .sha256 文件，由 SW 在 fetch 时异步获取
• 完整字节读取：必须用 response.arrayBuffer() 或 response.blob() 获取原始二进制；禁用 response.text()（会破坏非 UTF-8 字节）
• 单次流消费与分流：原 Response.body 只能读一次。需先 response.clone()，一份用于计算 SHA-256，一份用于构造新响应返回给页面

校验失败时的健壮响应策略

直接抛错或返回空响应会导致 JS 执行中断、图片不显示、白屏等严重体验问题：

• 记录错误详情（URL、预期哈希、实际哈希）并上报监控服务
• 返回原始响应（不阻断渲染），同时向页面发送 postMessage 提示资源异常
• 可选降级：尝试从备用 CDN 或本地 fallback 缓存中加载同名资源
• 禁止静默替换内容——任何修改都应可审计，避免引入新的不可信行为

安全前提不可绕过

所有依赖 Service Worker 构建的防护机制，都建立在两个基础之上：

• HTTPS 强制启用：HTTP 下 SW 不会被注册（除 localhost），防止中间人替换 SW 脚本本身
• 元数据传输可信：哈希值、签名、清单文件等，必须通过 HTTPS 传输，且建议由服务端签名验证（如 JWT 或 detached signature）