How to Share a HAR File Without Leaking Credentials

A HAR records what the browser actually sent

A HAR archive is a JSON log of network activity. Each entry can include request and response headers, cookies, the parsed query string, request bodies, and often response bodies. Anyone holding the file can read a session cookie or bearer token and replay an authenticated request for as long as that credential remains valid.

Capture the smallest useful reproduction

Reduce the exposure before it exists. Clear the network log, reproduce only the failing action, and stop recording immediately afterwards. A capture that also contains the login exchange, unrelated tabs, or a long browsing session multiplies the amount of sensitive material that has to be removed.

• Clear the log immediately before reproducing.
• Reproduce one failing request rather than a whole session.
• Prefer a throwaway or test account when the bug allows it.

Redact by field name, not by reading through it

Manual review misses things in a file with thousands of lines. Redact systematically by field: authorization and proxy-authorization headers, cookie and set-cookie, and any header, parameter, or body field whose name suggests a token, key, session, password, or credential. Query strings deserve particular attention because access tokens and signed URLs frequently travel there.

Rotate anything that was already exposed

Redaction protects the next copy of the file, not the one that has already been emailed or attached to a ticket. If a capture containing a live token left your machine, revoke or rotate that credential. Browser tooling can help here too: Chrome DevTools offers a sanitized HAR export alongside the full one, and the sanitized version is the safer default.

What a capture can expose