Why a HAR needs cleaning
A HAR records what your browser sent, and your browser sends proof of who you are with almost every request: session cookies, Authorization: Bearer … headers, API keys, CSRF tokens. A sign-in recorded in a HAR also captures the password you typed. Most of these stay valid for hours or days, and a person holding them does not need your password to use your account.
This is not hypothetical. In its October 2023 write-up, Cloudflare described an attack on its systems that started from an authentication token stolen from Okta's customer support system, where the attacker had taken an HTTP Archive (HAR) file. Cloudflare released its own HAR sanitizer shortly afterwards.
What HARscope removes
| Where secrets hide | Examples | What happens |
|---|---|---|
| Cookies | Cookie, Set-Cookie, the cookies lists | Values become [REDACTED]; cookie names stay, so you can still see which cookies were sent |
| Auth headers | Authorization, Proxy-Authorization | The scheme stays (Bearer [REDACTED]) |
| Token headers | X-API-Key, X-Auth-Token, X-Auth-Key, X-CSRF-Token, any header ending in token, secret or api-key | Value redacted |
| URLs | ?access_token=, api_key, code, signature, X-Amz-Signature, user:pass@ | Value replaced with REDACTED in every URL in the file, including Referer and redirect targets |
| Anywhere | JWTs (eyJ…), bearer tokens, AWS, Stripe, GitHub, Slack, Google and OpenAI-style keys, private key blocks | Found by pattern in headers, URLs and bodies |
| Request bodies | JSON, form and multipart fields such as password, otp, client_secret, card_number, and the same fields in WebSocket messages you sent | Value redacted, the rest of the body kept |
| Responses | JSON fields such as access_token, refresh_token, csrfToken, secret; CSRF <meta> tags and hidden token inputs in HTML pages; bodies stored as base64 text | Value redacted |
| Email addresses | Anywhere in the file | Replaced |
Two stronger options are off by default: removing all request bodies, and removing all response bodies. Turn the second on if the pages themselves show private data such as account details or customer records; timings, headers and status codes are kept, which is usually what support needs.
How to do it
- Drop the .har file into the tool at the top of this page.
- Open the Sanitise tab. The default rules are already applied.
- Read What was removed. Each row shows the request, where the value was, the field name and a masked preview. Tick Show removed values if you need to check one.
- Switch rules on or off. The list updates immediately.
- Click Download redacted HAR. The copy is named
…redacted.harand carries a note inlog.commentsaying it was sanitised and how many values were changed.
After redacting, HARscope scans the output again for JWTs, bearer tokens and known key formats and tells you if any remain. One will only remain if you switched the matching rule off.
Does Chrome's “sanitized” export do this already?
Partly. Chrome's and Edge's documentation say their default Export HAR (sanitized) leaves out sensitive data such as the Cookie, Set-Cookie and Authorization headers. They do not say anything about tokens in URLs, custom API-key headers, passwords in form posts or tokens in response bodies, so assume those are still there. Firefox's and Safari's documentation describe no sanitizing at all. Running any of them through the sanitiser covers the gaps.
What no automatic tool can know
Rules match the names and formats that secrets usually have. Your app may use its own: a header called X-Tenant that is effectively a password, an internal customer number, a field named q that holds a search for a patient's name. Look through the request list for anything specific to your product before you send the file, and remove response bodies if in doubt.
Also remember that redacting a HAR does not end the session it recorded. If a full, unredacted HAR has already been shared, sign out of the affected sessions and rotate any API keys it contained.
Related: How to create a HAR file · Open a HAR file and read it