A HAR archive can explain why a page failed, but it can also contain the credentials and data that made the page work. URLs, cookies, authorisation headers, request bodies and response content can all carry sensitive values. Review the archive before it reaches a support ticket.
Start by deciding what the recipient needs to diagnose. A timing problem may require request order and durations but not response bodies. A failed API payload may need a small synthetic reproduction rather than an entire browsing session. Capture and share the minimum useful evidence.
Know where sensitive data can appear
The HAR privacy audit parses a selected archive locally and flags recognised patterns. It is a review aid, not a guarantee that every application-specific secret has been found. Unusual field names and encoded bodies can hide information beyond a generic detector's rules.
A HAR contains entries describing requests and responses, with fields for headers, cookies, query parameters, post data, content and timing. Export options and browser versions can change which data is included. Do not assume a file is safe because one browser's default export omits some sensitive headers.
Inspect both the structured fields and any repeated raw representation. A token may appear in the URL string and in a queryString array. Redacting one copy while leaving another defeats the review.
| Location | Possible data | Review approach |
|---|---|---|
| Request headers | Bearer tokens, API keys, cookies | Remove or replace secret values |
| URLs and query fields | Reset links, signed URLs, user identifiers | Review both raw URL and parsed parameters |
| Request bodies | Passwords, form data, uploaded content | Keep only fields needed for reproduction |
| Response headers | Set-Cookie values and internal routing details | Preserve useful attributes without live secrets |
| Response content | Personal records, documents, account data | Remove bodies or use synthetic samples |
| Timing and addresses | Activity patterns and infrastructure context | Share only the necessary scope |
Create a narrow reproduction
Use a test account and synthetic data when possible. Open the network panel, clear unrelated entries and perform only the steps needed to reproduce the failure. Stop recording after the relevant result. A full day of browsing rarely helps a focused support issue.
Decide whether preserve-log is needed for redirects or navigation. It can retain valuable evidence across page changes, but it can also collect more of the session than intended. Review the beginning and end of the exported entries rather than assuming the visible panel contains only the latest page.
Record browser version, approximate time, expected behaviour and the failing action separately in the support note. These details often reduce the amount of raw archive data needed. A concise reproduction can be more actionable than a large unexplained file.
Use consistent replacements that preserve the bug
Replace sensitive values with clear synthetic markers or remove them according to the recipient's needs. If the same account ID appears across several requests and that relationship matters, use the same replacement consistently. Avoid turning every value into unrelated text that destroys the request sequence.
Preserve header names, content types, status codes and timing fields when they are relevant. A CORS issue may require Origin and response policy headers, while an authentication issue may need to know that an Authorization header existed without retaining the live token.
Do not make a redacted archive look like an untouched original. State what categories were removed or replaced. That helps support understand why a request cannot be replayed directly or why a content length no longer matches a modified body.
Prepare a HAR for a failed file download
Suppose a download fails after a redirect to a signed storage URL. The archive contains the application's session cookie, the signed query string and a response body with a user's document metadata. Support needs the redirect sequence and error status, not the live credentials.
Keep the relevant request order, hostnames where appropriate, methods, status codes and timing. Replace the signed query values and session cookie. Remove the private response body or replace it with a synthetic example preserving only the field shape needed to explain the error.
Check every representation of the signed URL, including redirect Location headers and request URL fields. A token removed from the final request can still remain in the preceding response's Location value. Search the redacted file for the original secret and distinctive account identifiers.
Load the redacted archive into a suitable local viewer and confirm the sequence still makes sense. Share the redacted copy through the intended support channel, retaining the original only in an appropriately restricted location if it is still needed.
Inspect encoded and nested content
HAR response content can be encoded, and request bodies can contain nested JSON, form data or application-specific formats. A token may be inside a JSON string embedded within another field. A search for obvious header names will not find every such value.
Decode only as needed for review and preserve the format's semantics. Base64 is not encryption; encoded content can contain the same sensitive data as readable text. If the body is irrelevant, removing it may be safer and simpler than trying to recognise every secret inside it.
For binary uploads or large content, confirm whether the export includes actual bytes, summaries or only metadata. Do not assume an attachment is absent because it is not displayed as plain text. Review the export's fields and the browser's documented behaviour.
Verify the redacted file structurally and semantically
Keep valid JSON syntax. A manual edit that removes a quote or comma can make the archive unusable. Use a structured editor or script appropriate to the file, then validate the result before sharing.
Review semantics too. If a request body is changed, fields describing its size or encoding may no longer match. Decide whether to update or remove those fields and disclose the transformation. A structurally valid archive can still mislead support if its metadata contradicts the modified content.
Run the local audit again and search for known original values. A clean detector result is one check, not the final verdict. Manually review fields specific to your application, such as tenant IDs, document names, custom auth headers and internal service URLs.
Respond if a live secret was already shared
If an unredacted archive containing active credentials was sent, use the relevant service's revocation or session sign-out controls. Deleting the ticket attachment may reduce further exposure, but it cannot guarantee that every recipient or backup copy disappeared.
Identify which credentials were present: session cookies, API tokens, reset links or signed downloads can have different revocation paths and lifetimes. Follow the service's incident process and review access where available. Do not assume that a password change invalidates every token in the archive.
Keep the response proportionate to the actual contents and exposure. A HAR containing only public assets is different from one containing an administrative bearer token. Inspect the evidence and apply the controls relevant to the affected secrets.
Set a retention boundary for support evidence
Store the original and redacted versions separately with clear names. Restrict the original to those who need it, and remove it when the investigation and applicable retention requirements allow. A generic downloads folder is a poor long-term location for session-bearing evidence.
Tell the recipient the reproduction time, relevant entries and redaction categories. Avoid asking them to search hundreds of unrelated requests for an unspecified problem. A focused note and narrow archive reduce both privacy exposure and debugging effort.
For recurring support workflows, provide a documented capture-and-review process using test accounts where feasible. Automation can flag known patterns, but the process still needs an owner who understands the application's data.
Frequently asked questions
Does a browser's sanitised export remove every secret?
No generic export can know every application's sensitive fields. It may omit common credentials while leaving identifiers, signed URLs or response data. Review the actual archive and the browser's export options rather than assuming the label guarantees complete redaction.
Can the local audit guarantee the file is safe to share?
No. It detects recognised patterns and helps focus review. Application-specific secrets and encoded data can escape detection. Re-run it after editing, then inspect the remaining fields against the purpose of the support request.
Should I remove all headers?
Remove sensitive values while preserving evidence needed for the issue. CORS, caching and redirect problems often depend on specific headers. Use synthetic values and explain the changes so the recipient can interpret the archive correctly.
Is Base64 content private?
No. Base64 is an encoding and can be decoded without a key. Review encoded bodies or remove them if they are unnecessary. A secret is not protected merely because it is not immediately readable in the JSON file.
Can a HAR replay log someone into my account?
If it contains valid bearer credentials or session cookies, a recipient may be able to use them according to the service's controls. Treat such values as secrets, redact before sharing and revoke them if exposure has already occurred.
What if redaction prevents exact reproduction?
Use a test account or synthetic fixture that reproduces the relevant behaviour. If deeper evidence is necessary, arrange an authorised restricted process with the support owner. Do not default to publishing live credentials in an ordinary ticket.
What is the final sharing check?
Confirm valid structure, useful request sequence, absence of known secrets, review of application-specific data and a clear note about redactions. Share only the intended copy through the appropriate channel and retain the original under a defined access and retention policy.