Service Worker不能主动识别非法篡改，仅程序化控制请求响应流程；其fetch事件仅拦截同源或合法跨域的页面主动请求，且必须依托HTTPS与可信元数据（如Content-Digest头）实现哈希校验闭环，失败时应上报、降级或透传原始响应，严禁静默替换。
service worker 本身不能“强制拦截非法篡改请求”——它不检测“非法”或“篡改”，也不具备主动识别攻击的能力。它的作用是**程序化地控制已发起的请求与响应流程**，安全防线必须由开发者基于可信元数据、确定性校验和明确策略来构筑。关键不在“拦截动作”，而在“拦截后做什么”。
哪些请求能被真正拦截并可控处理
Service Worker 的 fetch 事件只对满足以下全部条件的请求生效：
- 由当前受控页面主动发起（如
fetch()、XMLHttpRequest、<img alt="通过 Service Worker 强制拦截非法篡改请求构筑安全防线" >、<script></script>、<link>等） - 同源，或跨域但响应头含有效
Access-Control-Allow-Origin - 非导航主文档请求（除非注册时
scope显式覆盖且页面匹配） - 非
sendBeacon()、非<iframe src="xxx"></iframe>内部资源、非 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）
