HAR文件清洗器
从HAR文件中移除认证令牌・Cookie等敏感数据。
🖥 Removes cookies, auth headers, tokens, and bodies from a HAR file — entirely in your browser, so secrets never leave your machine.
概述
HAR 文件是浏览器自己记录下来的一次页面加载过程，从 DevTools 导出。它是「在我这里是正常的」这类缺陷报告里你能附上的最有用的东西，同时也是最不该粘进公开 issue 追踪系统的东西之一。一份登录状态下的抓包，包含你的会话 Cookie、你的 Authorization 请求头、当时恰好在传输中的任何 OAuth code、你提交过的每一个表单，以及服务器返回的每一个响应体。
这个工具重写抓包内容，让结构留下来而机密消失。请求列表、方法、状态码、请求头名称、耗时和大小都还在——也就是维护者推理你这个问题所需要的一切——而那些一旦泄露就会危及你账号的值，会被替换为 [REDACTED]。
使用方法
- 在 DevTools 里打开 Network，右键请求列表，选择 Save all as HAR。
- 把 JSON 粘贴到这里（或者打开文件，把内容粘进来）。
- 先看被脱敏字段的计数，再快速通读一遍输出。
- 点 Download 保存
sanitized.har，附件用这个文件，而不是原始文件。
会被移除的内容
同一个机密会在一份抓包里出现在好几个不同的位置，所以工具必须把它们全部清掉。漏掉其中任何一处，才是真正要命的那种失败：一份看起来已经脱敏过的文件，比一份明显没脱敏的文件更危险，因为前者会让你不加思索地就把它附上去。
- 请求头。
Cookie、Set-Cookie、Authorization，以及任何名称里含有token、secret、credential、session或api-key的头。还有Location，因为 OAuth 回调之后的重定向会把授权码带在 URL 里。 - 解析后的 cookie 数组。 HAR 会把 cookie 记录两遍——一次是原始的头部行，一次是名值对形式的
cookies[]数组。这些数组里的每个值都会被清空，不看名称，因为 cookie 的名称并不能说明它的用途（现实中s、_sess和SID都是会话 cookie）。 - 请求体。
postData.text和解析后的postData.params[]都会被清空，同样不看字段名。登录表单的字段可能叫pass、otp或cvv，这些名字没有一个会出现在你想得到的关键词列表里。 - 响应体。 整体清空。这是意外泄露的最大单一来源——比如
/api/me返回的那个 JSON，里面装着一整条用户记录。 - 重定向目标和 WebSocket 帧。
response.redirectURL，以及 Chrome 的_webSocketMessages——它的第一帧十有八九就是认证握手。 - 服务器 IP 地址和发起方。
serverIPAddress会暴露内网编址；Chrome 的_initiator保存着触发该请求的那个脚本的完整 URL，查询串也在里面。 - 查询参数。 任何名字像凭据的参数——
token、api_key、AWSAccessKeyId、signature、code、state、sid，以及包含key、secret或password的名称。像page和lang这样与机密无关的参数会被保留，好让 URL 仍然可读。 - 页面标题和来源页。 页面标题往往就是 URL 本身，而 OAuth 回调之后的
Referer头会带着授权码。
刻意保留的内容
有两类内容即使粗暴的关键词过滤会命中，也照样留着，因为删掉它们等于毁掉你分享这个文件的理由：
- CORS 响应头。
Access-Control-Allow-Origin及其同类不含任何机密，而 CORS 问题本来就是分享 HAR 最常见的原因之一。把答案本身涂掉，抓包就没用了。 - 认证挑战。
WWW-Authenticate和Proxy-Authenticate描述的是服务器想要哪种认证方式。那是提示，不是凭据。
这个工具做不到的事
基于名称来判断的脱敏有一个明确的上限，在把输出附到公开 issue 之前，值得先弄清楚这条线画在哪里。
- 藏在 URL 路径里的机密。 在不了解路由的前提下，
/reset/9f3c…和/invite/abc123与/users/42没有任何区别。路径片段被原样保留，因为删掉它们会毁掉请求列表。 - 名字无害的自定义头里的令牌。 一个叫
X-Client-Id的头，如果恰好携带了签名值，不会命中任何关键词。分享之前请自己扫一遍头名称。 - 非机密参数里的个人数据。
?email=里的邮箱地址会留下来，因为email是字段名而不是凭据。这算不算问题，取决于你把文件发给谁。 - URL 本身。 内网主机名、预发布域名和 API 路径全部保留，它们合起来就描述了你的架构。
实用的判断标准是：这个工具让抓包可以安全地附到厂商工单，或者你自己追踪系统里的 issue。「可以公开发到互联网上」是另一个层面的判断，要靠你自己把文件读一遍来下结论。
说明
这些值是被替换掉而不是被删除，所以 JSON 的形状保持不变，任何 HAR 查看器都还能打开处理后的结果。唯一的例外是 content.encoding：当一个响应体被替换掉时，那个用来描述原始字节的 base64 声明会被一并去掉，因为 [REDACTED] 本身不是 base64，严格的查看器碰到它会直接报错。
计数器报告的是「被清空或移除的字段数」，而不是「找到的机密数」。一份完全没有任何 cookie 的静态站点抓包，也完全有可能报出一个很高的数字，因为每一个响应体都算作一处。
不是 HAR 格式的输入会被直接拒绝，而不是原样放行。这个工具早期的版本会接受任意 JSON，处理了零条记录，然后把「0 sensitive values redacted」当成成功结果报告出来——等于把原始文件连同一份健康证明一起交还给你。这个页面的全部产品价值就在于「告诉你某个东西是安全的」这件事上，所以现在只要缺少 log.entries 数组，工具就会拒绝处理。
如果你只想读一份抓包而不是分享它，请用 HAR 查看器。它在屏幕上遮蔽机密，但从不重写文件，因为两种方式下都没有东西离开你的机器。