HAR Security & Recon Analyzer

About this tool

A HAR file is the browser's full recording of a session: every request and response with headers, cookies and often bodies. That makes it useful for finding out what an application does, and risky to share, because it usually contains live session cookies, tokens and passwords. This tool reads a HAR in your browser, and the file is never uploaded. It summarises requests, hosts (marking third-party hosts), methods, status classes and file types, groups requests into endpoints with identifiers folded together, and lists the query and form parameters it saw. It then reports security-relevant things the recording shows: credentials or secret-looking parameters sent over plain HTTP, any plain-HTTP traffic, secrets in URLs, plain-HTTP resources in an HTTPS session, redirects from HTTPS to HTTP, pages without a Content-Security-Policy, HSTS, X-Content-Type-Options, framing protection or a Referrer-Policy, cookies with weak attributes (using the same parser as the Set-Cookie analyzer), CORS answers that reflect the request origin with credentials, wildcard with credentials or the null origin, version numbers in Server and X-Powered-By, responses with credentials that a shared cache could store, error pages that show stack traces, and a note that the file itself holds credentials. The redacted copy works on a deny-by-default basis: every query-string and form value is masked, cookies keep their names but lose their values, only a short list of ordinary headers (content type, cache control, server and similar) keeps its value, user names and passwords in URLs are removed, JWTs and bearer tokens are masked wherever they appear, and request and response bodies are removed by default. If you choose to keep bodies, masking becomes best effort: JSON and form keys that look like secrets, markup values and key-value text are masked, but a secret with no label around it cannot be recognised. It was tested on a HAR recorded by real Chrome against a deliberately careless server, with planted secrets that must not survive redaction, and on 600 randomly placed secrets in headers, cookies, URLs, fragments, bodies, multipart parts, form fields and WebSocket messages, in both body modes. Skim the redacted file before you share it. A header that is missing in a capture may be added by a CDN in front of the real site, so treat findings as things to check.

How to use it

1. In your browser's developer tools open the Network tab and save the session as a HAR file.
2. Load the file here (or paste its JSON) and press Analyze.
3. Open the findings from high to low severity and check the affected requests.
4. Before sharing the recording, download the redacted copy and skim it.

Common problems

The file will not load

It must be JSON with log.entries. Very large files (over about 120 MB) are refused; export a shorter session.

Response bodies are missing from the redacted copy

That is the default, because bodies cannot be cleaned reliably (request bodies are replaced too, except plain forms with masked values). Untick the option to keep them with best-effort masking, and read the result before sharing.

A header is reported missing but I know it is set

The recording shows only what your browser received. If you exported from behind a proxy or a cached response, headers can differ from production.