事件捕获阶段全局拦截敏感操作方法

本文揭示了一个常见误区：试图用DOM事件捕获阶段（如addEventListener的useCapture=true）拦截fetch、localStorage、copy等敏感操作是根本无效的，因为这些行为完全脱离DOM事件流；真正可行的拦截必须深入运行时底层——通过劫持全局API（如window.fetch）、Proxy代理存储接口、重写Clipboard方法，或借助Chrome扩展的webRequestBlocking等原生权限机制；但技术难点不在于“能否拦截”，而在于如何在严控风险的同时避免阻塞正常业务逻辑，例如同步扫描请求体可能拖垮性能，异步上报又面临数据泄露窗口，这种安全与可用性的精细平衡，才是落地成败的关键。

不能靠事件捕获阶段做全局敏感操作拦截——它只管 DOM 事件，而敏感操作（如 fetch 外发、localStorage 写入、copy 文本、document.execCommand 截图触发）大多不经过 DOM 事件流。

为什么 addEventListener 捕获模式对敏感操作无效

事件捕获阶段（useCapture = true）仅适用于可冒泡/可捕获的原生 DOM 事件，比如 click、keydown、input。但真正危险的操作往往绕过 DOM：

• fetch / XMLHttpRequest 是纯 JS API，不触发任何事件
• 复制文本可能走 document.execCommand('copy') 或 Clipboard.writeText()，后者甚至需要用户手势，不暴露给事件监听器
• 文件下载、iframe 导航、postMessage 跨域通信都不在事件流中
• 即使监听 beforeunload，也无法阻止已发起的异步外发请求

真正能拦截的入口只有三个：全局函数劫持、代理对象、浏览器扩展 API

想在逻辑执行前干预，必须替换或包裹原始行为，而非监听事件：

• 劫持 window.fetch 和 window.XMLHttpRequest.prototype.send：检查 url、body、headers 是否含敏感词或目标域名
• 用 Proxy 包裹 localStorage / sessionStorage 的 setItem 方法，校验键名和值内容
• 重写 navigator.clipboard.writeText，加入同步内容扫描（注意：需在安全上下文且有用户手势）
• 若需拦截截图类行为（如 html2canvas 渲染），只能靠 Object.defineProperty 封禁关键 canvas 方法或检测 document.hidden + performance.now() 异常高频调用

Chrome 扩展是唯一可靠方案，但需明确权限边界

纯前端 JS 无法拦截所有敏感路径；生产环境真正落地的方案，是通过 manifest.json 声明权限后，在扩展 content script 中实现：

• 用 chrome.webRequest.onBeforeRequest 监听并阻断外发请求（支持匹配 URL、method、requestBody）
• 用 chrome.storage.local 存敏感词库，比前端内存更难被绕过
• 配合 chrome.runtime.sendMessage 向页面注入防护逻辑，但不能直接访问页面 DOM —— 需用 executeScript 注入沙箱脚本
• 注意：activeTab 权限下无法拦截后台请求；要拦截所有请求，必须声明 "webRequestBlocking"，且用户安装时会看到明确提示

真正难的不是“怎么拦”，而是“拦住之后怎么不破坏业务”。比如劫持 fetch 后若同步扫描 body，会阻塞整个请求链路；而异步上报又可能漏掉已发出的数据。这类权衡点，往往比技术实现本身更决定方案成败。

文中关于的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《事件捕获阶段全局拦截敏感操作方法》文章吧，也可关注golang学习网公众号了解相关技术文章。