A HAR file is an auth dump: a 30-second safe-sharing checklist

Hanna Dev — Fri, 24 Jul 2026 08:27:58 +0000

When support asks for a HAR file, the request sounds harmless: reproduce the bug, export a log, attach it to a ticket.

But a HAR is not just a performance trace. It can be a snapshot of an authenticated browser session.

Depending on the page and workflow, it may contain:

Authorization headers and API keys
session cookies, including values from cookies that JavaScript cannot read
access tokens in query strings or request bodies
email addresses, account IDs, internal hostnames, and document URLs
request and response payloads with actual user data

That makes "send me the HAR" closer to "send me a temporary auth dump" than "send me a screenshot."

The 30-second checklist

Before attaching a HAR to any ticket, chat, or public issue:

Capture the smallest possible reproduction. Open a fresh tab, start recording immediately before the failing action, and stop immediately after it. Fewer requests mean fewer secrets and less noise.
Prefer a disposable or test account. If you must use a real session, plan to revoke it after capture.
Inspect the risky surfaces. Search request headers, cookies, query parameters, POST bodies, and response bodies—not only URLs.
Redact values without destroying structure. Support usually needs header names, status codes, timings, initiators, and the request sequence. Replace secret values consistently instead of deleting whole objects.
Verify the sanitized copy. Search it again for emails, bearer tokens, cookie values, API-key prefixes, and identifiers you already know.
Ask what is actually required. A support engineer may need one failed request and its response, not the entire browsing session.
Revoke what can be revoked. Logging out, rotating a key, or expiring the captured session is cheap insurance.

Why manual redaction fails

A quick global search-and-replace can miss encoded or repeated values. Deleting every Cookie, Authorization, or response body can also remove the evidence needed to diagnose the incident.

The useful target is not "a clean-looking JSON file." It is a shareable copy that preserves diagnostic shape while reducing credential exposure.

For example, this still tells an engineer what happened:

Authorization: [REDACTED: bearer_token]

This often does not:

<entire header object deleted>

Consistent placeholders also help: if the same account ID occurs in three requests, replacing it with the same token preserves correlation without exposing the original value.

A safer support workflow

My preferred sequence is:

capture → minimize → detect → redact → verify → share → revoke

The important design constraint is location. A sanitizer should not require uploading the sensitive original to an unknown server before it can make the file safe.

I built a small browser-only experiment called ReqRescue around that constraint. The current version reads the HAR in your browser tab, ranks likely incident evidence, and prepares a sanitized export. There is no account and the synthetic demo needs no real HAR.

If you have 15 seconds, run the synthetic demo and answer one question: does the top-ranked finding show enough evidence and confidence to suggest a useful next action?

Important limit

Secret detection is heuristic, not a mathematical guarantee. Encodings, proprietary token formats, and application-specific identifiers can evade any generic detector. Always review the sanitized output before sharing it, and never upload secrets to a tool you do not trust.

What secret pattern or support workflow should a local HAR sanitizer handle next?

DEV Community: Hanna Dev

A HAR file is an auth dump: a 30-second safe-sharing checklist

The 30-second checklist

Why manual redaction fails

A safer support workflow

Important limit