Your HAR file is a loaded weapon — sanitize it before sharing
Everything support needs to diagnose your problem is everything an attacker needs to become you. A HAR file records the full session — cookies, authorization headers, form fields, response bodies — captured while you were logged in. Handing over a raw HAR is closer to handing over your password than to attaching a log file.
This isn't theoretical. In October 2023, attackers breached Okta's support case management system and walked away with HAR files customers had uploaded to tickets. The session tokens inside were still valid, and both BeyondTrust and 1Password disclosed that stolen files were used to hijack real sessions. The tokens only worked because nobody had sanitized the captures.
What's actually inside
Cookie and Set-Cookie headers hold session IDs — replay them and you're logged in, no password required. Authorization headers carry bearer tokens and API keys. postData captures whatever was typed while recording: login forms mean passwords, checkout forms mean card numbers. Query strings leak password-reset tokens and OAuth codes. And content — the response bodies — can hold your email, name, address and anything else the page showed you.
Why "I'll just delete the cookie line" isn't enough
Secrets hide where a quick scan won't look. The same session ID appears in the cookies array and the Cookie header and sometimes the URL itself. Tokens sit inside response bodies — hello, /api/me. Redirect chains leak state and code parameters through Location headers. Partial sanitization is the same as none, with extra confidence on top.
How to sanitize a HAR properly
Redact by category, never by find-and-replace: strip cookie values everywhere they appear, kill authorization and API-key headers, blank sensitive query parameters, scrub request bodies, and drop response content unless support explicitly needs it. Private IPs and internal hostnames are worth redacting too — they map your network for free.
The HAR viewer does all of this in one pass and shows a redaction report of exactly what was removed — entirely in your browser, so the unsanitized file never touches a server. You can verify that claim yourself: load the page, pull the network cable, and it still works.
Before you hit send
A thirty-second checklist: capture a fresh, minimal HAR of just the failing action — shorter file, fewer secrets. Run it through a sanitizer and read the report. Open the sanitized copy and search for your own email and any token you recognize. If there's any chance something survived, log out to invalidate the recorded session. Then share — through the vendor's official channel, not a public issue tracker.
HAR Viewer
Scan your capture for leaked cookies, tokens and keys — then export a sanitized copy
Frequently asked questions
Does a HAR file contain passwords?
It can. If you logged in, checked out or submitted any form while recording, postData captured exactly what you typed — passwords, card numbers and personal messages included.
Is it safe to send a HAR file to support?
Only after sanitizing. Legitimate support teams expect sanitized files — Okta itself recommends it since the 2023 breach. A vendor demanding a raw HAR deserves suspicion, not compliance.
Do the tokens in a HAR file expire?
Eventually — but that can mean hours or weeks depending on session lifetime, and API keys often never expire. Treat every credential in a HAR as live until you've logged out or rotated it.
Can I sanitize a HAR file without uploading it anywhere?
Yes — that's the point of doing it client-side. The .tools HAR viewer parses and sanitizes entirely in your browser; you can disconnect from the network after the page loads and every feature still works.