How to Sanitize HAR Files Before Sharing Proxy Debug Logs

A browser HTTP Archive file can make a difficult proxy incident reproducible. It records request order, redirects, status codes, timing phases, headers, and sometimes request or response bodies. The same detail also makes an unreviewed HAR dangerous to share: it may contain session cookies, bearer tokens, proxy credentials, customer identifiers, search terms, form values, internal hostnames, and complete API responses.

Modern browser tooling can exclude some sensitive fields by default, but that is only a capture-time safeguard. Export modes differ, older browsers remain in use, imported traces may come from other tools, and a user can explicitly choose an export that includes sensitive data. Treat every HAR as sensitive until a deterministic sanitizer and a second validation pass prove otherwise.

Decide what evidence the investigation actually needs

Do not begin by recording an entire workday. Write the diagnostic question first. A proxy team usually needs a narrow set of evidence:

• whether the browser connected directly or through the intended proxy path;
• the failing request, its redirects, status code, and response class;
• DNS, connection, TLS, request, wait, and download timing;
• a correlation identifier that is safe to disclose;
• the browser, operating system, proxy region, IP family, and UTC time window.

The team rarely needs live account cookies, full HTML pages, unrelated tabs, payment data, chat content, or every request generated by extensions. If a field cannot help answer the stated question, do not collect it.

Capture the smallest reproducible session

Create an isolated browser profile or temporary test account with synthetic data. Disable unrelated extensions, close other tabs, clear the Network panel, and start recording immediately before the reproduction. Stop immediately after the failure appears.

Use a test destination you are authorized to access. Never reproduce an incident against a third party merely to create a cleaner trace. If the failure requires authentication, use a short-lived test credential and revoke it after capture even when you expect the browser to redact it.

Record the capture context separately from the HAR:

Do not put proxy passwords, session tokens, or raw customer identifiers in this cover note.

Redact by parsing JSON, not by editing text

A HAR is structured JSON. Parse it, transform known locations, and serialize a new file. Global regular-expression replacement is unreliable: it can miss escaped values, damage valid JSON, or remove a harmless string while leaving the real secret in another field.

Start with an explicit denylist for header names, compared case-insensitively:

authorization
proxy-authorization
cookie
set-cookie
x-api-key
x-auth-token

Then inspect every request URL, query string, request body, response header, and response body. Token names are application-specific, so include patterns used by the affected system, such as access_token, refresh_token, session, signature, key, and code.

A minimal transformation can follow this shape:

const blockedHeaders = new Set([
  "authorization", "proxy-authorization", "cookie",
  "set-cookie", "x-api-key", "x-auth-token"
]);

function redactHeaders(headers = []) {
  return headers.map((header) => blockedHeaders.has(header.name.toLowerCase())
    ? { ...header, value: "[REDACTED]" }
    : header);
}

function sanitizeEntry(entry) {
  entry.request.headers = redactHeaders(entry.request.headers);
  entry.response.headers = redactHeaders(entry.response.headers);
  entry.request.cookies = [];
  entry.response.cookies = [];
  entry.response.content.text = undefined;
  return entry;
}

This is a starting point, not a universal sanitizer. Code defensively when optional objects are absent, preserve the source file unchanged in a restricted location only if policy requires it, and write sanitized output to a different path so the two files cannot be confused.

Handle URLs and bodies with an allowlist

URLs leak data through query parameters, path segments, and fragments. Replace sensitive parameter values while preserving parameter names when those names help diagnosis. If a path embeds an account, email address, order number, or signed object key, replace that segment with a stable placeholder.

Request and response bodies deserve stricter treatment. A safe default is to remove all bodies. Retain a body only when the investigation cannot proceed without it and an allowlist defines the permitted media type and fields. For JSON, recursively remove sensitive keys. For forms, replace every value unless a field is explicitly approved. For binary, compressed, multipart, or unknown content, drop it.

Do not keep a secret's first or last characters to make it recognizable. Partial tokens can still be useful to attackers and can help correlate datasets. If engineers must match the same non-secret identifier across entries, create a salted hash for this incident and destroy the salt when the case closes.

Preserve diagnostic value deliberately

Sanitization should not turn a useful trace into an empty shell. Keep evidence that answers the original question when it is safe:

• request method and sanitized origin or route label;
• HTTP version, status code, redirect order, and error text that contains no user data;
• timing phases and transfer sizes;
• safe request and response headers such as content type, cache control, and a reviewed correlation ID;
• connection identifiers, server address, and certificate metadata only when disclosure is approved;
• the exact entry that failed plus a small number of dependencies needed to explain it.

If hostname disclosure is restricted, replace origins with stable labels such as proxy-gateway, target-api, and identity-service. Include a private mapping in the internal ticket, not in the shared archive.

Validate the sanitized file as if the first pass failed

Never rely on the sanitizer's exit code alone. Run a second, independent inspection:

1. Parse the output again to confirm valid HAR-shaped JSON.
2. Search case-insensitively for blocked header names and known secret-field names.
3. Scan for the exact test username, email, tenant, token, cookie name, proxy endpoint, and internal hostname used during capture.
4. Detect common bearer, JWT-like, cloud-key, private-key, and high-entropy token patterns.
5. Open the sanitized HAR in a clean test profile and confirm that the required failure sequence remains understandable.
6. Have a second person review high-risk traces before external sharing.

A match does not always prove a secret remains, but every match needs an explanation. Record the sanitizer version, ruleset revision, output checksum, reviewer, and review time in the incident ticket.

Share through a controlled case package

Use an access-controlled case system with an expiry, named recipients, and download logging. Avoid public links, personal cloud folders, chat uploads, and email attachments. Share the sanitized HAR, a short reproduction note, the expected result, the observed result, and the safe correlation identifiers together.

Set a deletion date before sending. Ask the recipient to confirm deletion when the case closes. If the trace crosses organizations or regions, verify the data-processing agreement, retention terms, approved support location, and incident-response contact first.

For related testing, use the 98IP guides on replaying a failed request safely, diagnosing proxy authentication failures, and separating proxy throttling from target throttling.

Release checklist

• [ ] Capture used an isolated profile, synthetic data, and the shortest possible window.
• [ ] Credentials were short-lived and revoked after capture.
• [ ] The sanitizer parsed JSON and wrote a separate output file.
• [ ] Authorization, Proxy-Authorization, cookies, API keys, and application tokens were removed.
• [ ] URLs, paths, query parameters, request bodies, and response bodies were reviewed.
• [ ] Unknown or binary bodies were dropped.
• [ ] The output passed a second secret scan and manual review.
• [ ] The remaining trace still reproduces the diagnostic sequence.
• [ ] Access, recipients, retention, deletion, and cross-border handling were approved.

FAQ

Is the browser's default HAR export safe enough?

It is a valuable first control, not a release decision. Browser version, export option, extensions, imported data, and application-specific fields can change what the file contains. Always sanitize and validate the exported artifact.

Should Proxy-Authorization be treated differently from Authorization?

No. Both can carry reusable credentials or challenge responses. Remove their values, and also review proxy usernames embedded in URLs or tool-specific metadata.

Can we share only the single failing entry?

Often yes. Include only the redirects or dependencies required to understand it. Data minimization is preferable to redacting a much larger capture.

Is hashing personal data sufficient?

Not automatically. Stable unsalted hashes can be reversible through guessing and still enable correlation. Remove the field when possible; otherwise use a case-specific salt under an approved policy.

Compliance note

Capture only traffic, accounts, and systems you are authorized to test. Apply least privilege, data minimization, documented purpose, controlled access, short retention, and secure deletion. A HAR may contain personal data or authentication material even after an automated tool reports success, so human review remains mandatory before it leaves the incident boundary.

Research note: Chrome DevTools documentation for Chrome 130 describes sensitive-data exclusion in HAR exports by default, while the Chrome DevTools 152 release published on 25 August 2026 reflects the current Network tooling context. External research locations are retained only in the internal operations record.