service worker 无法拦截三方 iframe 的嵌入请求，因其仅能拦截本域页面主动发起的同源请求（如 fetch、img、script），而 iframe 的主文档加载由外站发起且属跨源导航请求，不在 sw 作用域内；防御点击劫持须依赖服务端响应头（如 content-security-policy: frame-ancestors 'none'）或前端运行时跳转兜底。
Service Worker 无法拦截三方 iframe 的请求来防止点击劫持。
为什么 SW 拦截不了 iframe 的嵌入行为
点击劫持的本质是恶意页面用 <iframe src="your-site.com"></iframe> 把你的页面“套”进去，再用 CSS 遮盖、透明化、精确定位，诱导用户误点。这个过程里：
- iframe 的加载由**外站页面主动发起**，不属于你站点的受控上下文
- Service Worker 只能拦截**本域页面主动发出的请求**（如 fetch、
<img>、<script></script>），对被别人嵌入时产生的导航请求（即 iframe 的主文档加载）无权干预 - 浏览器在加载 iframe 时，不会让目标站点的 SW 参与控制——SW 的作用域只属于它注册所在的 origin 和 scope，不延伸到跨源嵌入场景
真正有效的防御手段是 HTTP 响应头
阻止被嵌入，必须在服务端明确声明策略，主流且兼容性好的方式有两种：
- X-Frame-Options: DENY —— 完全禁止任何站点用 iframe 加载该页面
-
Content-Security-Policy: frame-ancestors 'none' —— RFC 标准方案，效果同上，且支持更细粒度控制（如
frame-ancestors 'self' https://trusted.com'）
二者选其一即可，推荐优先使用 CSP 的 frame-ancestors，因它更现代、可组合、已被所有主流浏览器支持。
辅助手段：前端运行时检测与跳转
作为兜底，可在页面 JS 中加入简单判断：
if (window.top !== window.self) {
window.top.location = window.location;
}
该逻辑会在被 iframe 嵌入时触发顶层跳转，强制跳出嵌套环境。注意它有局限性：
- 仅对同源或宽松 CSP 的嵌入有效（跨域 iframe 中脚本可能被限制访问
window.top） - 存在极短时间的“闪现”，用户体验略差
- 不能替代服务端响应头，仅作补充
别被“拦截请求”误导
有人尝试在 SW 的 fetch 事件中匹配 iframe 的 URL 并返回 403，这是无效的：
- iframe 主文档请求（navigation request）默认不在 SW 拦截范围内，除非显式将
scope设为'/'且注册页与目标页同源，但即便如此，SW 对导航请求的响应能力受限（不能随意改写 HTML 文档流） - 即使强行 respondWith 一个错误响应，浏览器通常仍会显示空白或错误页，而非阻止嵌入——攻击者页面照常存在，只是你的内容没加载出来，这不等于防御成功
- 这种做法混淆了“资源加载失败”和“嵌入被拒绝”的安全语义，反而掩盖真实风险
