How to Sanitize HAR Files and Remove Sensitive Data Before Sharing

Key takeaways:

• HAR files are credential-equivalent artifacts — a single stolen HAR gave attackers admin access in the 2023 Okta breach
• Chrome's built-in "Sanitize" option only strips cookies, leaving Authorization headers, bearer tokens, and API keys exposed
• Client-side sanitization is the only safe approach — uploading HAR files to online tools creates the same exposure risk you're trying to prevent
• Seven specific data patterns require redaction: cookies, auth headers, bearer tokens, API keys, session IDs, OAuth tokens, and PII in request/response bodies

When a support engineer asks you to "export a HAR file and attach it to your ticket," they are asking you to hand over the keys to your kingdom. A HAR file from an authenticated browser session contains every cookie, every Authorization header, every bearer token, and every API key that flowed through your browser during that session. And in October 2023, that exact scenario led to one of the most consequential breaches in identity security history.

What makes a HAR file a credential-equivalent artifact?

A HAR file is a credential-equivalent artifact because it stores complete HTTP request/response pairs including session cookies, Authorization headers, bearer tokens, and OAuth refresh tokens. A single HAR file from an authenticated session gives anyone who obtains it the same access as the logged-in user, bypassing MFA entirely. The 2023 Okta breach proved this: attackers extracted session tokens from a support-submitted HAR file and accessed admin dashboards at Cloudflare and BeyondTrust.

The HAR (HTTP Archive) 1.2 specification was designed for debugging. It captures everything: request URLs with query parameters, request headers (including Authorization), request bodies (including login forms), response headers (including Set-Cookie), and response bodies (including OAuth token endpoints). A typical authenticated session HAR contains 15 to 40 credential-equivalent values spread across cookies, auth headers, and token endpoints.

Here is the critical detail most people miss: session tokens extracted from a HAR file are functionally identical to stolen passwords for the duration of the session. Unlike passwords, session tokens bypass multi-factor authentication completely. The attacker never needs your password or your phone. They just need the HAR file.

In the Okta incident, an employee shared a HAR file with Okta's support team. That HAR contained a valid session token. Attackers who compromised Okta's support system extracted the token and used it to access customer admin dashboards at Cloudflare and BeyondTrust. No MFA prompt appeared. No credential theft was needed. The HAR file was the credential.

The attack surface is enormous. Major SaaS vendors — Okta, Zendesk, Salesforce, AWS — routinely request HAR files from customers for debugging. These files travel through ticketing systems, often stored in plaintext in support databases. Every HAR file sitting in a support ticket is a potential credential breach waiting to happen. Under OWASP Top 10 A02:2021 (Cryptographic Failures), sharing unredacted HAR files through support tickets creates a supply chain vulnerability that most organizations never consider.

This is not a theoretical risk. This is what sanitization — the umbrella term covering techniques like masking, tokenization, and redaction — was designed to prevent. And for HAR files specifically, the stakes could not be higher.

Why Chrome's built-in HAR sanitization is not enough

In 2024, Chrome added a "Sanitize" checkbox to its DevTools HAR export. This was a step in the right direction — but it creates a dangerous false sense of security. Here is what Chrome's sanitize option actually does versus what it leaves behind:

Chrome's sanitize feature strips cookies — and only cookies. Every other credential-bearing mechanism in modern web applications remains fully intact in the exported file. Authorization headers with bearer tokens, API keys passed as query parameters, OAuth access and refresh tokens in response bodies, session identifiers embedded in URLs — all of these survive Chrome's sanitization untouched.

Firefox's Network Monitor and Safari's Web Inspector offer no HAR sanitization at all as of early 2026. If you export a HAR from either browser, you get everything, completely unredacted. There is no checkbox, no warning dialog, and no indication that the file contains sensitive data.

Even Edge, which shares Chrome's DevTools, only recently inherited the sanitize option. And across all browsers, there is no standardized approach to HAR sanitization — the HAR 1.2 specification itself does not address security or data minimization.

The result is that developers who check Chrome's "Sanitize" box believe they have removed sensitive data from their HAR file. They have not. They have removed one category of credential while leaving six other categories fully exposed. This is worse than no sanitization at all, because it creates confidence without security.

To properly sanitize a HAR file and remove sensitive data, you need to target seven specific patterns. Each one represents a different mechanism by which modern web applications transmit credentials.

Cookies and Set-Cookie headers

Every Cookie request header and Set-Cookie response header must be redacted. While Chrome's export handles this, manual review should verify nothing was missed. Match pattern: "name": "Cookie" or "name": "Set-Cookie" in the headers arrays.

Authorization and Bearer token headers

The Authorization header is the primary credential vector in modern APIs. It typically contains Bearer <token> values that grant full API access. Match pattern: "name": "Authorization" in request headers.

API keys in query parameters and headers

API keys frequently appear in URL query strings (?api_key=..., ?key=...) and custom headers (X-API-Key, X-Api-Token). These keys often have no expiration and grant persistent access. Match pattern: query parameters or headers containing api_key, apikey, key, token, or secret.

OAuth tokens in response bodies

OAuth2 flows return access tokens and refresh tokens in response bodies. A refresh token is particularly dangerous because it can generate new access tokens indefinitely. Match pattern: "access_token", "refresh_token", "id_token" in response content.

Session identifiers in URLs

Some applications embed session IDs directly in URLs (/session/abc123/resource or ?sid=abc123). These are visible in the HAR file's URL fields. Match pattern: URL segments or parameters containing session, sid, jsessionid.

PII in POST request bodies

Form submissions and JSON API calls often contain personally identifiable information — email addresses, phone numbers, social security numbers, credit card numbers. These appear in the postData section of requests. Match pattern: standard PII patterns (email, phone, SSN formats).

Custom authentication headers

Many applications use non-standard authentication headers: X-API-Key, X-Auth-Token, X-Session-ID, X-CSRF-Token. These vary by application but follow common naming conventions. Match pattern: headers with X-API, X-Auth, X-Session, X-CSRF prefixes.

Each of these patterns requires specific attention. Missing even one category can expose credentials that grant full access to the user's session or API resources. This is why manual sanitization is error-prone and automated detection catches patterns that manual review misses — the 73% failure rate of manual redaction applies directly to HAR file sanitization.

How to sanitize HAR files without uploading them anywhere

The first rule of HAR file sanitization is: do not upload the HAR file to an online tool. This sounds obvious, but it is the most common mistake. Uploading an unsanitized HAR file to a web-based "HAR viewer" or "HAR sanitizer" exposes every credential in the file to that service's servers. You are trying to protect credentials by sending them to a third party. The irony should be apparent.

Method 1: Manual JSON editing

A HAR file is just JSON. You can open it in any text editor and search for sensitive values. Look for "Authorization", "Cookie", "Bearer", "access_token", and API key patterns. Replace values with placeholder text like [REDACTED].

The problem: a typical HAR file from a 10-minute authenticated session can be 5-50 MB of JSON with hundreds of request/response pairs. Manual editing is tedious, error-prone, and takes 20-45 minutes per file. You will miss things.

Method 2: Browser-based tools that process locally

The safe alternative is a client-side tool that processes data entirely in your browser, with zero server communication. Paste the HAR JSON content into a tool like obfuscate.online, which uses the same tokenization approach used for pseudonymizing datasets — it detects sensitive patterns (tokens, keys, credentials, PII) and replaces them with safe placeholders. The data never leaves your browser.

This approach gives you the automation benefits of a tool (consistent pattern matching, no missed credentials) without the security risk of uploading. The original data stays on your machine. The sanitized version is what you share with support.

Method 3: Scripted sanitization for CI/CD pipelines

For organizations that generate HAR files as part of automated testing (Selenium, Playwright, Cypress), you can build sanitization directly into your pipeline. Parse the HAR JSON programmatically, iterate through all entries, and replace values matching the seven patterns above with deterministic placeholders. This ensures no HAR file ever leaves your build environment unsanitized.

A basic approach: load the HAR as a JSON object, walk every request.headers and response.headers array looking for sensitive header names, walk every request.queryString for API key parameters, and scan request.postData and response.content for token patterns. Replace each match with a placeholder that preserves the structure (so the HAR remains valid JSON) while removing the sensitive value.

The advantage of scripted sanitization is repeatability. Once you build the script, every HAR file goes through the same process automatically. No human judgment required, no credentials missed, no files accidentally shared unsanitized.

Building HAR sanitization into your support workflow

Most organizations share HAR files reactively — a support engineer asks for one, and the developer exports and attaches it without thinking about what is inside. Building sanitization into the workflow prevents credential exposure before it happens.

Pre-sharing checklist:

1. Export with Chrome's Sanitize checkbox enabled — this removes cookies as a baseline, even though it is not sufficient on its own 2. Run the HAR through a client-side sanitizer — detect and replace all seven credential patterns listed above 3. Verify the sanitized output — spot-check that Authorization headers, API keys, and token values have been replaced 4. Document what was redacted — tell the support engineer which data types were removed so they can request specific values if genuinely needed for debugging 5. Set an expiration for the ticket — ensure the HAR file is not stored indefinitely in a support system

When to use automated analysis versus manual review: use automated pattern detection for every HAR file. Reserve manual review for cases where the automated tool flags ambiguous content — for example, values that look like tokens but might be legitimate non-sensitive identifiers.

The goal is to make sanitization the default, not the exception. Every HAR file shared with support should go through this process. The 30 seconds it takes to run a sanitizer is trivially cheap compared to the cost of a credential breach.

Organizational policy recommendations

For security-conscious organizations, HAR file handling should be part of your data handling policy. Consider these additions:

• Classify HAR files as confidential — they contain credential-equivalent data and should be treated with the same controls as passwords or private keys
• Require sanitization before external sharing — make it a policy that no unsanitized HAR file leaves the organization, whether to vendors, support teams, or bug bounty reporters
• Rotate sessions after sharing — even after sanitization, invalidate the session that was captured in the HAR file as a defense-in-depth measure
• Train developers on HAR file risks — most developers export HAR files without understanding what they contain; a 5-minute training session can prevent credential exposure
• Audit support ticket attachments — periodically scan support ticket systems for unsanitized HAR files that may have been uploaded before the policy was in place

FAQ

What sensitive data is stored in a HAR file?

A HAR file stores complete HTTP request/response pairs including session cookies, Authorization headers with bearer tokens, API keys in query parameters, OAuth refresh tokens in response bodies, and any PII submitted through forms or JSON payloads. A single HAR from an authenticated session contains enough credential data to fully impersonate the user.

Does Chrome's HAR sanitize option remove all sensitive data?

No. Chrome's built-in "Sanitize" checkbox (added in 2024) only removes cookies and Set-Cookie headers. It leaves Authorization headers, bearer tokens in request/response bodies, API keys in URLs, OAuth tokens, and session identifiers in query parameters completely intact.

How do I sanitize a HAR file without uploading it to a server?

Use a client-side tool that processes data entirely in your browser. Paste the HAR JSON content into a browser-based sanitizer like obfuscate.online, which detects and replaces sensitive patterns (tokens, keys, credentials) with safe placeholders without any server communication. This prevents the circular risk of exposing credentials by uploading them to yet another service. For automated pipelines, you can also build a script that parses the HAR JSON and replaces sensitive values programmatically before the file leaves your local environment.