Strip the secrets out of logs and HAR files before you share them

"Can you send me a HAR file?" is a reasonable request from a support engineer and a dangerous thing to comply with unthinkingly. A HAR export is a complete recording of a browser session: every request, every response header, every cookie sent, and often the response bodies too. Handing one over unedited gives the recipient the ability to act as you on any site in that recording, for as long as those sessions live.

The same applies, less obviously, to the log snippets people paste into tickets, Slack threads and chat windows all day. It is worth having a routine.

What is actually in a HAR file

HAR is JSON, and it is exhaustive by design. In a normal export you will find:

• Session cookies for every domain touched, in full, as sent. This is the big one — a session cookie is a bearer credential, and the recipient does not need your password to use it.
• Authorization headers, including bearer tokens and basic-auth credentials, which are trivially decodable.
• Tokens in query strings. Password reset links, signed URLs, API keys passed as parameters, OAuth codes mid-flow.
• Request bodies. Everything you typed into a form during the recording, including the login form if the recording started before you signed in.
• Response bodies. Depending on the export options, the actual data — customer records, account details, internal API payloads.
• Everything else you had open. A HAR is per browser tab, but analytics beacons, extension traffic and background refreshes from other services land in it too.

The HAR file sanitizer takes the export and strips the credential-bearing parts — cookies, auth headers, tokens — while leaving the request and response structure intact, which is what the person debugging your problem actually needs. Paste it, get a cleaned file, attach that.

Look at what you are sending

Sanitising blind is better than not sanitising, but the useful habit is looking first. Copy the headers of the suspicious request out of your dev tools and run them through the HTTP header parser: it breaks a raw block into name/value pairs you can read, which makes it obvious when there is an X-Internal-Auth or a vendor-specific token header that a generic redaction pattern would not have recognised as a secret.

Cookies deserve their own look. Paste a Cookie or Set-Cookie line into the cookie parser and you get each cookie broken out with its attributes — HttpOnly, Secure, SameSite, expiry. That is a redaction check ("which of these are session tokens?") and a security review at the same time: a session cookie without HttpOnly or with a year-long expiry is a finding in its own right, and you are already looking at it.

Terminal output has two problems

Pasted terminal logs carry secrets — connection strings, tokens in curl commands, environment dumps — and they also carry ANSI escape sequences. Those are the reason a colourful log turns into ESC[0;32m noise when it lands in a ticket, and they make the text hard for anyone to read and hard for you to search. The ANSI stripper removes the colour and cursor-control codes and leaves the text.

Then redact. The data redactor finds the recurring categories — email addresses, IP addresses, phone numbers, card numbers, key-shaped strings — and replaces them consistently, so the log still reads as a coherent trace instead of becoming a wall of [REDACTED]. Consistency matters when you are debugging: if the same user ID is replaced with the same placeholder everywhere, the reader can still follow one request through fifty lines.

Pattern matching will not catch a secret that looks like ordinary text, so read the result before you send it. Internal hostnames, customer names in free-text fields and file paths containing usernames are the three things that survive every automated pass.

Redaction is not rotation

The most important point, and the one people skip: if a credential has already been sent somewhere it should not have gone, removing it from a document does nothing. The recipient may have it. It may be in an email archive, a ticket system, a chat backend, someone's local download folder, or a model provider's logs.

Rotate. Invalidate the session, revoke the token, roll the API key. Then clean the file. In that order, because the cleaning takes a minute and the rotation is the part that actually closes the exposure.

Pasting into a chat window is publishing

Debugging with an assistant is normal now, and a stack trace with a connection string in it goes to a third party the moment you hit enter. Depending on the product and the plan, that text may be retained, reviewed by a human, or used for training. Treat any paste into a hosted model as a transfer to an outside party — because that is what it is — and sanitise it exactly as you would sanitise an attachment to an external email.

This is the case where local tooling is not a preference but the whole point: every tool named here runs in your browser, so the un-redacted version of the file is never uploaded to anything on its way to being cleaned. Sanitising a secrets-bearing log by pasting it into a website that processes it on a server means the secret has already left, whatever the cleaned output looks like.

A checklist worth pinning

1. Record the HAR in a private window with only the relevant tab open, and start recording after you have logged in.
2. Run the export through the sanitizer.
3. Open the cleaned file and search it for token, secret, key, auth, password and your own domain names.
4. Strip ANSI codes from any terminal output, then redact identifiers.
5. Read the result end to end. It is shorter than you think.
6. Rotate anything that was live in the original.
7. Send it through a channel that expires, not one that archives forever.

Six minutes of work against a credential leak that would otherwise sit in a ticket queue indefinitely.