Sanitize HAR Files for Vendor and Support Escalations

Problem

HAR files are useful for reproducing issues, but they can contain cookies, API tokens, and sensitive request bodies.

Sending raw HAR files to vendors can increase compliance risk and slow down approvals.

Solution

HAR sanitizer applies rule-based masking to headers, params, and JSON keys while keeping trace structure intact.

You can also preload custom rules for cloud, vendor, or product-specific workflows.

What we redact

Examples

• Cookie: [REDACTED:COOKIE_VALUE]
• client_secret: [REDACTED:KEY]
• access_token=[REDACTED:QP]

Use cases

• Submit browser network traces to external support safely.
• Share reproducible incident data with security review teams.
• Standardize HAR hygiene across regional support teams.
• Prepare SOC2-ready evidence handoff workflows.

FAQ

If your support process depends on HAR exports, this page helps teams keep technical context without sharing secrets.

Why HAR files are higher risk than screenshots

A HAR file is a structured record of browser network activity. It can include request URLs, query strings, headers, cookies, response headers, timing information, JSON payloads, form fields, and redirect chains. That makes it useful for vendor support, but it also means a single export can contain session cookies, CSRF tokens, bearer tokens, account ids, internal hostnames, and customer data.

Screenshots usually show the visible failure. HAR files show the transport details behind the failure. Before sending one outside your team, treat it like a sensitive incident artifact.

What to inspect before sharing a HAR

Start with cookies and authorization headers. Browser exports frequently include Cookie, Set-Cookie, Authorization, x-csrf-token, and vendor-specific API key headers. Next, inspect query parameters such as token, signature, session, auth, code, and state. Finally, review JSON request and response bodies for email addresses, customer ids, addresses, payment references, and private notes.

The HAR sanitizer preserves the trace shape so support can still see request order, method, status code, resource path, and timing. Sensitive values are replaced with placeholders so the reviewer can understand that something was present without receiving the raw value.

Example support handoff

A useful sanitized HAR handoff usually includes:

• the sanitized HAR file
• the failing page or endpoint
• expected versus actual behavior
• approximate timestamp and timezone
• browser and environment
• request id or correlation id if available
• a note confirming cookies, auth headers, query tokens, and JSON secrets were masked

Avoid attaching multiple unrelated HAR files. If the vendor asks for a new trace, create a narrow reproduction and sanitize that file instead of sending a full browsing session.

What sanitized HAR output should preserve

The sanitized file should still answer practical debugging questions. Did the browser call the right endpoint? Was the response a 401, 403, 429, or 500? Did the request include the expected content type? Did a redirect remove a header? Did a preflight request fail before the main request? Those signals should remain visible after masking.

The values that should not remain visible are access credentials and customer data. If a cookie name is needed for debugging, keep the name and redact the value. If a JSON field name is important, keep the key and replace the value. If a query parameter proves a flow was signed, keep the parameter name and mask the signature.

Team workflow

For repeated support operations, pair the HAR sanitizer with rule packs. A support lead can define custom header names and JSON keys that your product commonly uses, then share that configuration with the team. That reduces review drift and makes escalations more consistent across regions and shifts.

This page is indexable because it describes a distinct HAR workflow and gives concrete review criteria. Other HAR pages should stay out of the index until they add comparable depth.