A network archive can contain an active session
A HAR file is an HTTP Archive, commonly exported from a browser’s developer tools to diagnose a website problem. It can contain request URLs, headers, cookies, bodies, response information and timing data. That detail is useful for debugging, but it can also disclose credentials, personal information or the contents of a session to anyone who receives the file.
This auditor reads a selected HAR locally and highlights several categories of sensitive-looking data. It counts destination hosts, unencrypted requests, authentication headers, cookie headers, selected query names and entries with request bodies. It does not automatically sanitise the archive or certify that it is safe to share. The report intentionally avoids displaying detected credential values.
Export a narrow session and inspect its scope
When collecting a HAR for support, reproduce only the relevant issue if possible. A long session can include unrelated tabs, account pages, third-party services and background requests that are not needed to explain the problem. Clear the Network panel before reproduction and review the browser’s export options, which may offer different handling of sensitive headers.
The audit expects a JSON object containing log.entries. It rejects an unrelated JSON file rather than treating it as an empty network session. Inputs are limited to 25 MiB and 30,000 entries to keep parsing practical in a browser. For larger traces, reduce the recorded period or use a dedicated local analysis workflow.
The destination-host inventory helps you notice unexpected services and understand the breadth of the capture. A host other than the site’s visible address is not automatically a tracker: CDNs, authentication providers, APIs and support widgets can be legitimate dependencies. The tool groups hostnames but does not use a public-suffix database to assign corporate ownership or classify every host as first or third party.
The Overview tab explains the findings. Measured data lets you search individual fields and values, while JSON report shows the complete export. Export JSON to retain a baseline, or print the findings for your own records. Review the report before sharing it: browser characteristics, token claims, and file names can reveal information about your setup.
Review credentials, query fields and request bodies
Authorization, Proxy-Authorization and X-API-Key headers are common places for credentials. Cookie request headers can carry active session identifiers. The auditor counts those headers and describes why they deserve review without echoing their values. Their presence is enough to justify careful handling even if a support team says it only needs timing information.
Query parameter names containing patterns such as token, password, secret, session, API key or email are flagged. This is a heuristic, not a complete data-classification system. A secret can sit under a harmless-looking parameter name, inside a path segment, in a fragment copied by another tool or within a custom header that the pattern list does not recognise.
Requests containing postData are also counted. Body formats vary: JSON, form data, multipart uploads and binary content can all carry sensitive information. The audit does not recursively inspect every body or response payload. A report with no credential-header findings can still correspond to an archive full of confidential application data.
Redact a copy and preserve diagnostic usefulness
Keep the original archive privately if you need it for your own investigation, and prepare a separate redacted copy for sharing. Remove or replace live credentials, personal identifiers and irrelevant request or response content. Preserve the structure and fields necessary to reproduce the issue so that sanitisation does not make the support report impossible to interpret.
Check both request and response data. Authentication cookies can arrive in Set-Cookie response headers even when no Cookie request header was captured. Response bodies may contain account records, documents or tokens. This implementation focuses on selected request-side patterns and reports its limitations; it does not remove those other risks on your behalf.
If a live credential has already been shared with an unintended recipient, consider invalidating the session or rotating the key through the relevant service. Editing the file afterwards does not recall the previously disclosed value. The appropriate action depends on the credential’s scope, expiry and who received it.
Use a secure support channel and disclose the minimum data needed for the question. A HAR archive should not be posted publicly as an attachment to a general bug report without review. The exported audit summary is much smaller than the original and excludes values, but even a list of hostnames can disclose business services or internal workflow context.
What the audit looks for
| Pattern | Reason to inspect it |
|---|---|
| HTTP request | The recorded URL uses unencrypted transport. |
| Authentication header | The archive may contain a reusable token, key or credential. |
| Cookie header | A recorded session identifier may grant account access. |
| Sensitive-looking query name | The URL may carry personal information or a token. |
| Request body present | Payload data requires manual, format-aware review. |
Strengths and limitations
What this is useful for
The tool surfaces high-value review targets without uploading the archive or repeating credential values in its report. Host counts and request categories help narrow a large capture. It rejects invalid structure and places clear resource limits around browser parsing.
What to keep in mind
Pattern matching cannot discover every secret. The audit is not a sanitiser and does not comprehensively inspect response bodies, arbitrary custom fields or every encoded payload. A clean report is not permission to share an unreviewed archive. The hostname inventory does not establish ownership or tracking intent.
Common questions
Does a HAR contain passwords?
It can. A captured login request, form body, query parameter or authentication header may include credentials or equivalent tokens. Export behaviour varies by browser and settings, so never assume sensitive fields were removed automatically. Inspect the actual file and use disposable test accounts when practical.
Will this remove secrets from my file?
No. The auditor produces a summary and selected findings while leaving the original archive unchanged. Automatic redaction can miss application-specific data or destroy useful context. Prepare a separate redacted copy and review it before sharing; the result here is an aid to that process.
Is the archive sent to a server?
No. The selected file is parsed in the current browser tab. The report contains aggregate counts and hostnames rather than the full archive or detected credential values. Browser extensions, clipboard tools and your operating system are outside this application’s control.
Why are response cookies and bodies not fully audited?
HAR payloads can contain many formats and arbitrary application data. This implementation performs a defined set of request-side pattern checks rather than claiming universal secret detection. Review response headers and bodies separately, especially Set-Cookie, JSON account responses and downloaded documents.