Clean a network log before you send it INTERCEPT

What is in a .har that people do not expect

A support engineer asks for a HAR file. You open the network tab, right click, Save all as HAR, and send it. What you have just sent is a complete recording of every request the browser made while you were logged in.

That includes the Cookie header on every request, which is your session: whoever holds it is logged in as you until it expires, without a password and without a second factor. It includes every Authorization header, so bearer tokens and basic credentials in full. It includes API keys in custom headers, CSRF tokens, the bodies of every form you submitted and every JSON payload, and the complete responses, which is to say your own data.

Handing one over unredacted is a routine cause of account takeover, and it happens because the file is opaque: it is a single line of JSON megabytes long, there is no obvious moment where you are asked to look inside it, and the person asking for it is legitimately trying to help you.

What this replaces and what it leaves

It streams through every request and response in the file and replaces the value of each known credential field with a labelled placeholder, so the shape of the exchange survives: the engineer can still see that a cookie was present and what it was called, which is usually the diagnostic information they actually needed. The same treatment works on a pasted curl command or a block of request headers, for a bug report or a piece of documentation.

It is pattern-based redaction of the fields that carry credentials. It is not a guarantee that the file is safe, and it says so rather than implying otherwise. A secret can sit in a URL path rather than a header. A company can use a custom header this does not know about. A response body can contain a token, a personal record, or somebody else's data altogether, and no pattern distinguishes that from ordinary JSON.

So read the summary and skim the result before you send it. The summary exists for that: it tells you what was found and where, which is also the fastest way to discover that your application is putting a key somewhere it should not.

Opening a file also lays it out to be read: every request with its status, size and time, a waterfall of when each one ran, the hosts it reached with the third parties grouped, and the headers and bodies of any request you open. A request that carries a cookie, a token or a key is marked by the same rules the cleaner uses, so you can see what will be replaced before you save.

Better still, capture less

The cleanest HAR is one that never recorded the login. If you can reproduce the problem in a private window, in a test account, or after clearing the network log and doing only the failing action, do that first: there is nothing to redact in a recording that contains one request.

And treat a sanitised HAR as reduced risk rather than as safe. Send it through whatever channel the support desk actually controls rather than an open ticket a search engine can find, and assume it will be kept.

For the neighbouring problems: ENVSHIELD does the same job for a .env file or a configuration dump, JOT reads a token you found so you can see what it grants, and DATASCAN finds personal data in a spreadsheet before it leaves.