Sanitize a HAR file

Browsers responded: Chrome's DevTools now offers a sanitized HAR export, and vendors like Okta sanitize HARs on upload. These are real improvements centered on the obvious carrier — cookies. But cookies are one of many places a HAR holds secrets. An Authorization header rides on every API call. API keys travel in query strings (?api_key=…), JWTs sit in URL paths and OAuth redirect fragments, the login POST carries a password in its body, the token endpoint's response echoes access and refresh tokens back — frequently base64-encoded, where a text search will never find them. And no browser can know that your vendor's X-Api-Key or X-Amz-Security-Token header is a credential. A vendor-side upload sanitizer only helps when you upload to that vendor — the copy you attached to an email, a Slack thread, or a different ticket system got no such treatment.

It walks the HAR's structure rather than treating it as a blob of text. Cookie values — in Cookie and Set-Cookie headers and in the structured cookies arrays — are masked by position, because the format itself says what they are; names and attributes stay. Headers and parameters with credential-shaped names (authorization, x-api-key, session_token and relatives) have their values masked whole, even when the value looks harmless. Everything else that is text — URLs, remaining header values, query strings, request bodies, response bodies, comments — is scanned by the same pattern engine that powers this site's log file redactor: emails, IPv4/IPv6 addresses, JWTs, AWS keys, Bearer tokens, and key=value credentials. Base64 response bodies are decoded, scanned, and re-encoded — but only when they decode cleanly to text. Anything binary or undecodable is left byte-for-byte intact and its entry is flagged, because a sanitizer that corrupts entries is a sanitizer people stop trusting.

Masked values become placeholder tokens, and the same value always becomes the same token: the session cookie in the request header, the cookies array, and the next entry's request all show [COOKIE-1], so the causality a reviewer needs (“this response set the cookie that request sent back”) survives sanitization. The output stays valid HAR and loads in any viewer, and sanitizing an already-sanitized file changes nothing.

Detection is pattern-based and incomplete by construction; any tool claiming otherwise is overpromising. The specific gaps: a secret under a bland name — a header called X-Ticket, a parameter called ref — is only caught if its value matches a known pattern or is long and random enough for the suspicious-string flagger (random strings under about 20 characters stay below its statistical floor). Prose-shaped passwords are invisible to entropy measures. Binary bodies are never inspected — their entries say so. And it can over-mask: JavaScript in a response body containing password=… looks exactly like a credential assignment, and masking it is the safer failure. That is why the viewer exists: each entry shows what was masked and what merely looks suspicious, side by side with the original, so the final human review takes minutes, not an afternoon of scrolling JSON.

Files are processed entirely in this tab's memory with a 20 MB ceiling. Scanning runs on the page's main thread, so a large HAR can freeze this tab for a few seconds — nothing is being uploaded during that pause; there is no network activity at all, which you can verify in DevTools. If your HAR is over the limit, filter the capture in the Network panel (or re-record just the failing requests) and export again. The page works offline once loaded, and nothing persists after the tab closes.

Sharing a single request instead of a whole capture? A copied-as-cURL command is one HAR entry rendered as shell — the curl command sanitizer gives it the same header, cookie, and body treatment without touching the quoting.