A HAR file is a complete recording of a browser's HTTP traffic, and if it was captured while the user was signed in it usually contains working session cookies and bearer tokens that let anyone who reads it become that user. Support teams ask for HAR files every day to troubleshoot sign-in, SSO and API problems, and they end up attached to tickets, emailed, pasted into chat and stored for years. In 2023 an attacker with access to Okta's support case system read HAR files that customers had uploaded and used session tokens from them to hijack the Okta sessions of five customers. This guide explains what a HAR file contains, what sanitised exports remove and what they miss, how to capture and share traces safely, how to run a support intake that does not become a token store, and how to respond when a HAR file leaks. It is for support and customer success teams, developers, identity administrators and security teams.
Key takeaways
- A HAR file can be a live credential. It records request and response headers, cookies, query strings, posted form data and response bodies, so session cookies,
Authorizationheaders and tokens in URLs or JSON bodies are all inside. - Sanitised export helps but is not complete. Chrome's default "Export HAR (sanitized)" removes the
Cookie,Set-CookieandAuthorizationheaders; tokens in URLs, request bodies, response bodies and custom headers can remain. - Support systems are credential stores. Any system that receives HAR files needs scrubbing on upload, short retention, tight access and audit logging, just like a secrets store.
- Short, bound sessions limit the damage. Session lifetimes, IP or device binding and re-authentication for admin actions make a copied token far less useful.
- Treat any token found in a shared file as leaked. Revoke the sessions and tokens, then check for use; do not wait to prove misuse.
What a HAR file contains
HAR (HTTP Archive) is a JSON format for exporting the HTTP transactions a browser makes. The W3C Web Performance Working Group's draft specification for HAR 1.2 was never published as a W3C standard and is marked as abandoned, but browsers and tools still use the 1.2 structure. The draft requires UTF-8 encoding, allows custom fields that start with an underscore, and contains a privacy section warning that the format may contain privacy and security sensitive data and that user agents should notify users before the file is transferred.
| HAR object | What it records | Sensitive content it can hold |
|---|---|---|
log.creator, log.browser | Tool and browser that produced the file | Browser version, useful for fingerprinting |
entries[].request.url and queryString | Full request URL (without fragment) and parsed query parameters | OAuth authorisation codes, API keys and signed URL signatures passed as parameters, SAML artefacts |
request.headers and request.cookies | Every request header and cookie | Session cookies, Authorization: Bearer tokens, API key headers, CSRF tokens |
request.postData | Posted body as text or parameters | Passwords typed into sign-in forms, refresh tokens sent to token endpoints, SAML responses |
response.headers and response.cookies | Every response header and cookie | Set-Cookie values for new sessions |
response.content.text | Response body, as decoded text or base64 | Access, ID and refresh tokens returned by token endpoints, personal data from APIs |
pages, timings | Page titles and timing | Internal URLs and page names |
Two consequences follow. A trace taken during sign-in can include the password and the resulting session; a trace taken after sign-in includes the session cookies on every request. And because bodies are included, a HAR file from an application that uses bearer tokens in single-page apps often contains the token response itself, not only the headers that carry it.
What sanitised exports remove, and what they miss
Chrome DevTools now offers two exports. The default Export HAR (sanitized) excludes the Cookie, Set-Cookie and Authorization headers. Exporting with sensitive data requires first enabling Settings > Preferences > Network > Allow to generate HAR with sensitive data and then choosing Export HAR (with sensitive data); the copy and save menus offer the same pair. Microsoft's guide to capturing browser traces for Azure support uses the sanitised export in Edge and Chrome and advises signing in before starting the trace so that it does not capture account sign-in data.
| Location of the secret | Removed by Chrome sanitised export? | What to do |
|---|---|---|
Cookie and Set-Cookie headers | Yes | Still check the parsed cookies arrays in the file |
Authorization header | Yes | Check other auth headers your apps use |
Custom headers such as X-API-Key or vendor session headers | Not by the documented rule | Scrub by name with a sanitiser that knows your headers |
| Query strings (codes, keys, signatures) | Not by the documented rule | Redact parameter values such as code, token, key, sig |
| Request bodies (passwords, refresh tokens, SAML) | Not by the documented rule | Avoid capturing sign-in; redact postData |
| Response bodies (token endpoint JSON) | Not by the documented rule | Redact access_token, id_token, refresh_token fields or drop bodies |
Sanitised export is a good default for the person capturing the trace. It does not remove the need to scrub on receipt, because the support team cannot know which export option the customer used, or whether the file came from a browser or tool that has no sanitised option. Open source sanitisers exist, for example Cloudflare's HAR sanitizer project, but test any tool against your own applications' header names and token formats before relying on it.
HAR files that never touch a browser menu
Browsers are not the only source. HTTP debugging proxies, mobile app debugging tools and browser automation frameworks used in end-to-end testing can all write HAR files, and many have no sanitised option at all. Test suites that record HAR on failure store the files as CI build artefacts, where they inherit the artefact store's retention and access rules, and the test accounts in them often have real privileges in shared staging environments. Include these locations in secret scanning and retention policies, and give test accounts the least privilege that still exercises the flow. See the Secrets in Container Images and Build Artefacts Guide.
Capturing and sharing a trace safely
Give users and engineers a short, standard procedure, and put it in your support documentation where customers will find it before they export.
- Ask whether a HAR is really needed: console output, a screen recording, a correlation or request ID, or server-side logs often answer the question with no secrets.
- Use a test account where possible: reproduce the problem with an account that has no privileges and can be reset afterwards.
- Sign in first, then record: start the capture after sign-in unless the problem is the sign-in itself, so the password is not recorded.
- Record only the failing flow: enable "Preserve log", clear the log, reproduce once and stop recording.
- Export sanitised: use "Export HAR (sanitized)" in Chrome or Edge. Only export with sensitive data if support specifically asks for it and explains why.
- Sign out after capture: signing out, or revoking sessions from the account's security page, invalidates the session cookies in the file on applications that end sessions server-side.
- Share through the support portal, not email or chat: portals can scrub, restrict and expire files; inboxes and chat channels keep them forever.
Internally, apply the same rules to engineers sharing traces in tickets, pull requests and chat. A HAR file pasted into a team channel is a session token pasted into a team channel. See the JWT and Session Tokens in Code and Logs Guide for the wider logging problem.
Running a support intake that does not hoard tokens
The Okta incident showed that a support platform full of customer HAR files is a high-value target. The attacker used a support service account that could view and update cases; Okta later said the account's credentials had been saved in an employee's personal Google profile on a managed laptop. Files linked to 134 customers were accessed. See the Okta support system breach for the full sequence.
| Control | What it does | Notes |
|---|---|---|
| Scrub on upload | Automatically strips cookies, auth headers, known token parameters and token response fields before the file is stored | Keep the raw file only if a specific case needs it, in a restricted store |
| Detect secrets in attachments | Run secret scanning on uploaded HAR, log and text files | Alert the customer and revoke what you can when a live credential is found |
| Short retention | Delete HAR attachments when the case closes or after a fixed period | Map to a records retention rule (NIST SP 800-53 SI-12) |
| Least-privilege case access | Limit who and which service accounts can read attachments | Service accounts for support tooling are high-value NHIs: vault their credentials and monitor their use |
| Access logging | Record every attachment download with user, case and time | Lets you answer "which customers' files were read" quickly |
| Customer guidance | Tell customers to use sanitised export and sign out after capture | Put it on the upload page, not only in documentation |
Reducing what a leaked token can do
You will not catch every HAR file. Session design decides whether a leaked file is an incident or a non-event.
- Short session and token lifetimes: idle and absolute timeouts, and short-lived access tokens with refresh tokens that rotate. See the Token and Session Security Guide.
- Binding: bind sessions to a client so a copied cookie fails elsewhere. After its incident Okta made IP binding available for its products and Admin Console, invalidating sessions when the source IP changes. Device-bound session credentials go further by tying the session to a key held on the device. See the Device-Bound Session Credentials (DBSC) Guide.
- Re-authentication for sensitive actions: require fresh MFA for admin changes, so a stolen session cannot change policies or add users silently.
- Server-side session revocation: sign-out and "sign out everywhere" must actually invalidate the session on the server, not only delete the browser cookie.
- Hardware-backed MFA for administrators: Cloudflare's account of its response recommends hardware keys for all accounts and reviewing session expiry policies to limit hijacking.
Where identity fits
HAR leakage sits at the junction of human and non-human identity. The session in the file belongs to a person, but the systems that collect, store and process HAR files run on service accounts and integrations. In the Okta case a single support service account was the way in, and in the follow-on Cloudflare breach one service token and three service accounts that were not rotated after the Okta incident let the attacker return. Tokens in HAR files can also be NHI credentials: API keys in headers, service-to-service bearer tokens captured by an engineer debugging an integration, or signed URLs. Inventory them like any other secret. See the Secrets Management Guide.
Responding to a leaked HAR file
- Identify the sessions and tokens in the file: parse cookies, auth headers, query parameters and token fields; note the user, application and time of capture.
- Revoke: end the user's sessions server-side, revoke OAuth refresh tokens and rotate any API keys or signed URL secrets found.
- Look for use: search identity provider and application logs for the session or token being used from a new IP, ASN, user agent or device after the capture time. Okta's case was first spotted by BeyondTrust when a stolen cookie was used to attempt an admin login.
- Check what changed: new users, MFA resets, API tokens created, policy changes and new OAuth grants during the window.
- Find other copies: the same file may be in email, chat, the ticket system and downloads folders; delete them and record where they were.
- Escalate across organisations: if the file came from a customer or vendor, tell them quickly and act on reports from them; Cloudflare recommends acting immediately on compromise reports.
Detection and measurement
| Metric | What it shows | Target |
|---|---|---|
| Share of HAR uploads scrubbed automatically on receipt | Intake coverage | 100% |
| Live credentials found in uploaded attachments per month | Whether customer guidance works | Falling |
| Median retention of HAR attachments | Exposure window | Days, not years |
| Sessions reused from a new IP or device within minutes | Hijack attempts | Each alert investigated |
| Admin sessions with binding and re-authentication enforced | Blast-radius reduction | 100% of admin roles |
| Accounts with read access to support attachments | Access sprawl | Reviewed quarterly; falling |
- Alert on session anomalies: the same session identifier seen from two networks, or an admin console session that appears with no preceding sign-in event.
- Scan internal channels: secret scanning on chat, wiki and ticket attachments catches HAR files shared outside support tooling.
Common failure patterns
- Asking for "a HAR file" without instructions: customers export everything, during sign-in, with sensitive data.
- Trusting sanitised export: tokens in query strings, custom headers and token responses survive and are stored unscrubbed.
- Keeping attachments forever: years of customer sessions sit in a support platform whose service accounts are weakly protected.
- Sign-out that is client-side only: the session cookie in the file stays valid after the user "signs out".
- Slow escalation: a customer reports a suspicious session and the report waits in a queue while the attacker keeps access.
- Partial rotation after an incident: credentials believed unused are skipped, as in the Cloudflare breach.
Framework mapping
| Framework | Reference | How it applies |
|---|---|---|
| NIST SP 800-53 Rev. 5 | SC-23 Session Authenticity; AC-12 Session Termination; IA-11 Re-authentication; SI-12 Information Management and Retention | Session binding and revocation, re-authentication for sensitive actions, retention of support data |
| NIST CSF 2.0 | PR.DS-02 | Protecting data in transit, including traces shared with third parties |
| MITRE ATT&CK v20 | T1539 Steal Web Session Cookie; T1550.004 Web Session Cookie; T1552.001 Credentials In Files | Theft and reuse of sessions and credentials found in files |
| OWASP ASVS 5.0 | V16.2.5 (logging of sensitive data by protection level) | Applications should not write session tokens and secrets into their own logs and diagnostics |
Practitioner checklist
- Publish a capture procedure: test account, sign in first, record only the failing flow, sanitised export, sign out afterwards.
- Offer alternatives to HAR files (request IDs, console logs, screen recordings) and ask for HAR only when needed.
- Scrub HAR uploads automatically for cookies, auth and custom headers, token query parameters and token response fields.
- Run secret scanning on support attachments and internal chat, and revoke what it finds.
- Set short retention for HAR attachments and log every download.
- Include CI artefact stores and debugging proxy exports in secret scanning and retention rules.
- Vault and monitor the service accounts that support tooling uses to read cases.
- Enforce short sessions, server-side sign-out, binding and re-authentication for admin roles.
- Write a leaked-HAR runbook: identify tokens, revoke, hunt for reuse, find copies, notify.
Standards and references
- W3C Web Performance Working Group: HTTP Archive (HAR) format draft
- Chrome for Developers: Network features reference (HAR export)
- Microsoft Learn: Capture a browser trace for troubleshooting
- Okta: Security incident investigation closure
- Cloudflare: How Cloudflare mitigated yet another Okta compromise
- Cloudflare: HAR Sanitizer
- OWASP: Application Security Verification Standard 5.0
- MITRE ATT&CK: Steal Web Session Cookie
Related NHI Mgmt Group resources: JWT and Session Tokens in Code and Logs Guide · Session Hijacking and Cookie Theft Guide · Infostealer Logs and Session Token Abuse Guide · Token and Session Security Guide