What's Inside a HAR File — and Why You Should Scrub It Before You Share It

At some point a support engineer asks you to "send a HAR file," you open your browser's dev tools, export one, and attach it to a ticket. Most people do this without ever looking inside. They should look, because a HAR file is one of the most over-trusted artifacts in everyday operations.

What a HAR file is

HAR stands for HTTP Archive. It's a JSON file your browser produces that records, in detail, every network request a page made during a session: the URLs, the timing, the request and response headers, and often the request and response bodies. It exists for debugging — when something breaks in a web app, the HAR shows support exactly what the browser sent and received, so they can see where it went wrong.

That completeness is the point and the problem. "Every request, with headers and bodies" includes the requests that carried your credentials.

What's actually in there

Walk through what a normal authenticated session sends, and you'll see the issue:

• Cookie headers. Every request to the site carries your cookies — including your session cookie, the bearer token that is your logged-in session. A HAR captures these verbatim.
• Authorization headers. Bearer tokens, API keys, and basic-auth credentials ride in this header on API calls. All captured.
• Tokens in URLs and bodies. OAuth codes, reset tokens, and access tokens sometimes travel as query parameters or in JSON bodies. Captured.
• Personal and business data. Whatever the page loaded — account details, customer records — is sitting in the response bodies.

A HAR of an authenticated session is, in practice, a transcript that frequently contains live, unexpired credentials. Because a session token is a bearer credential — possession equals authentication — a captured session cookie is a working key to your account for as long as it's valid. Anyone who reads that HAR can potentially replay it and be you, without your password and without your MFA.

Why this bites people

The HAR feels like a log, and logs feel harmless. But you're not sending a description of your session; you're sending the session's actual keys. Then that file travels: into a ticketing system, onto a support engineer's laptop, maybe to a subprocessor, possibly into a third-party tool. Every hop is a place the live token can leak. The original act — "attach a HAR" — looked routine, which is exactly why the danger is invisible.

How to scrub one before sharing

The fix is to sanitize the HAR before it ever leaves your machine. Concretely:

• Strip Cookie and Set-Cookie headers from every entry.
• Strip Authorization headers and any custom auth headers your app uses.
• Remove token-bearing query parameters and body fields — anything that looks like access_token, id_token, code, session, api_key.
• Capture the smallest reproduction. Record only the requests that show the bug, not your whole session, so there's less to leak.
• Automate it. Don't rely on remembering at 2 a.m. Use a scrubbing tool or a small script in front of every upload, so sanitization isn't a judgment call.

Some browsers and tools now offer to redact sensitive fields on export; treat that as a floor, not a guarantee, and verify what actually came out.

The takeaway

A HAR file is a faithful recording of an authenticated session, which means it routinely contains the live bearer tokens that make that session yours. "Send us a HAR" is a reasonable request; uploading an unscrubbed one is handing over working keys. Scrub headers and tokens first, automatically, every time — and treat any HAR that left your control without scrubbing as a credential you need to rotate.