A useful debugging format with a wide view
A HAR archive records a browser’s network activity in a structured format. That makes it valuable for diagnosing slow requests, redirect loops and failed API calls. It can also include enough request context to reveal an active session or private application data. The fact that a file is “only a network log” does not make it harmless.
Depending on browser settings and export options, an archive may contain authorization headers, cookies, request bodies, response headers and response content. A password-reset link can be embedded in a URL. A session token can be carried by a header. A customer record can arrive in a JSON response with no field named password anywhere in it.
Before sharing, run the HAR privacy auditor to identify a few high-value review targets. Its summary is a starting point, not an automatic sanitisation certificate.
Capture the smallest useful reproduction
Clear the Network panel before reproducing the issue. Avoid recording unrelated browsing, and use a disposable test account where practical. A trace of one failed request is easier to review than an hour of background traffic mixed with account management and document downloads.
Record the reproduction steps separately. A support team often needs the request order, response status and timing, not every original body value. Explaining the visible failure can reduce pressure to share a much broader capture than the question requires.
Review the browser’s export options rather than assuming a label such as “sanitised” covers every application-specific secret. A browser can recognise standard sensitive headers while missing a custom field or an opaque token in a path segment.
Inspect requests and responses
Request headers are a natural first stop. Authorization can carry bearer tokens or other credentials. Cookie headers can contain session identifiers. Query parameters and form bodies may contain personal information or one-time actions. The audit counts selected patterns while deliberately avoiding their values in its output.
Now inspect the other direction. Set-Cookie response headers can establish a new session. API responses can contain documents, account profiles and access tokens. A clean request-side summary does not say that these responses are safe to distribute. Your application’s data model determines what needs redaction.
| Location | Possible sensitive material |
|---|---|
| Authorization header | A token that can be replayed while valid |
| Cookie / Set-Cookie | Session identifiers and account state |
| URL path or query | Reset links, signed URLs and personal identifiers |
| Request body | Form fields, uploads and submitted credentials |
| Response body | Customer records, documents and returned tokens |
Redact a copy while preserving the structure
Keep the original privately if it is necessary for your investigation. Prepare a separate redacted copy for support. Replace sensitive values with consistent harmless markers so the request flow remains understandable. Preserve enough structure to show whether a field was present and whether the same identifier occurred in several places.
Do not accidentally leave the same secret elsewhere. A token removed from one header may also appear in a response, URL or cached request. Automated search helps, but application-specific review is still necessary. A credential-shaped name is only a clue; an ordinary field called data can hold something confidential.
After editing, confirm that the archive is still valid JSON and can be imported by the intended tool. Send it through the organisation’s approved support channel with the reproduction steps. Avoid publishing the archive on a public issue tracker unless you have deliberately reduced it to non-sensitive test data.
If the original was already disclosed
Redacting a later copy does not invalidate a session token someone already received. Review the credential’s scope and expiry, and consider signing out sessions or rotating keys through the relevant service. Notify the responsible account or security team when the disclosure warrants it.
The safest outcome is a useful support report with minimal data. Browser version, exact error, request timing and a narrow redacted trace often communicate the problem more clearly than an unreviewed archive. Consult the browser’s Network documentation for the current export behaviour and treat the file according to what it actually contains.
Agree on the diagnostic question before capturing
Ask the support owner which request or browser behaviour needs investigation through the established support process. A slow page, a CORS failure and an authentication loop need different evidence. Once the question is clear, capture a focused reproduction rather than assuming the largest archive will be the most useful.
Use an account containing synthetic records when the issue can be reproduced there. If the failure depends on a particular account state, describe that state without copying unrelated customer data. A small fixture that preserves the failing condition often gives engineers a cleaner starting point.
Write down the visible steps and expected result while reproducing them. Include the approximate time and browser version. The archive shows network activity, but it may not explain which click the user made or why a response was considered wrong.
Follow one secret through every representation
Consider a download URL containing a temporary signature. The signature can appear in the initial API response, a redirect Location header, the final request URL and the parsed query parameter list. Redacting only the final URL leaves several recoverable copies.
Search the original archive for the complete value and for distinctive fragments, then review the surrounding entries. In the redacted copy, replace each necessary occurrence consistently or remove the irrelevant field. Do the same for account identifiers that appear in both paths and response bodies.
Keep relationships useful without retaining live authority. If three requests refer to the same account, a consistent marker such as TEST_ACCOUNT_1 can preserve that relationship. The marker should clearly indicate a replacement rather than resemble a real credential that support might attempt to use.
After redaction, inspect the archive in a local viewer and read the support note alongside it. Confirm that the relevant sequence remains understandable. If an edited body changes size, explain that the content was replaced so timing or length analysis does not assume the modified bytes were the original transfer.
Review fields that generic detectors cannot classify
An application may place credentials in a header named X-Access, a query parameter called ticket or an opaque body field. A detector cannot know every naming convention. Use the application's request schema and the support question to identify which values grant access or reveal private data.
Response bodies deserve particular attention because they can contain ordinary-looking business records. Names, addresses, document titles and transaction details may not resemble tokens. Decide whether the body is necessary at all before trying to redact every field individually.
Encoded content requires the same judgment. A Base64 body is not private merely because it is difficult to skim. If its contents are irrelevant, remove it; if they matter, inspect it with the appropriate local format tools and use synthetic data where possible.
Keep a clear handoff and retention record
Name the redacted file distinctly and keep the original in a restricted location only while it is needed. Attach the intended copy and describe the removed categories. A clear note prevents support from treating missing credentials as a new browser defect or assuming a synthetic body was the actual server response.
When the issue is resolved, follow the organisation's retention rules for both versions. If a secret was exposed, revocation is a separate action from file deletion. Track the affected credential's lifecycle through the service that issued it rather than assuming deleting an attachment recalls every copy.
Frequently asked questions
Is a HAR just a list of URLs?
It can include much more: request and response headers, cookies, posted data, response bodies and timing. The exact contents depend on the browser and export options. Inspect the actual file before sharing rather than relying on a general description of the format.
Can a clean audit result replace manual review?
No. Pattern detection can highlight common secrets, but it cannot know every application-specific field or private record. Review the archive against the diagnostic purpose and the application's data model. A clean result means no recognised finding was reported, not that every value is suitable for publication.
Should I remove all response bodies?
If they are unnecessary to the issue, removal can greatly reduce exposure. If a body is central to the failure, create a synthetic sample or retain only the necessary structure. Explain what changed so support can distinguish original wire evidence from a simplified reproduction.
Why does the redacted archive no longer import?
A manual edit may have broken JSON syntax or removed a structural field expected by the viewer. Validate the file and compare its shape with the original without restoring secrets. Use structured editing where possible, then verify the intended import path before sending the copy.
Does changing my password invalidate every token in a HAR?
Not necessarily. API keys, session cookies and signed download links can have separate lifetimes and revocation controls. Identify the actual credential types and follow the service's documented response. Password change is one possible action, not a universal recall mechanism.
Can I post a HAR on a public issue tracker?
Only after deliberately reducing it to information appropriate for public release, ideally from a synthetic account and narrow reproduction. Public archives can be copied and indexed. Use the project's private support route when the evidence still requires restricted data.
What should accompany the file?
Include reproduction steps, expected and actual behaviour, browser version, relevant time and the entries support should inspect. State the redaction categories. This context makes a smaller archive more useful and reduces requests for a broader unreviewed capture.