Support teams still ask customers for a HAR file when a page misbehaves, and that file can carry what another person needs to act as the customer: session cookies, authorization headers, request and response bodies. The evidence a bug report needs is smaller: the call that failed and the status it came back with, not the payload.
A HAR export can copy the session along with the failure
The HTTP Archive specification behind the HAR file format opens with a warning that it “was never published by the W3C Web Performance Working Group and has been abandoned”, under a historical draft date of August 2012. Its field list says what an export holds. Every request entry has a “List of header objects”, a “List of cookie objects”, a “List of query parameter objects” and “Posted data info”. Every response entry has its own cookies and headers, plus a content object whose text field is the “Response body sent from the server or loaded from the browser cache”.
Read as a security document, that list describes a session. The request headers are where the browser puts Cookie and Authorization. The response cookies are where a server sets a fresh session after a login. The posted data is where a sign-in form sends a password and a checkout form sends an address. The response bodies are whatever the application returned to the account that was signed in: names, emails, order histories, internal ids.
A debugging trace records traffic as it happened, and a signed-in user’s traffic is full of the user. The trouble starts when the trace leaves the machine that recorded it, because a support case is a poor place to keep a working session.
Okta’s support incident showed where the files end up
On 20 October 2023 Okta published Tracking Unauthorized Access to Okta’s Support System, an advisory signed by David Bradbury. It explains the ordinary practice first: “Within the course of normal business, Okta support will ask customers to upload an HTTP Archive (HAR) file, which allows for troubleshooting of issues by replicating browser activity.”
Then the incident. An attacker “leveraged access to a stolen credential to access Okta’s support case management system” and “was able to view files uploaded by certain Okta customers as part of recent support cases.” The advisory names the risk in one line: “HAR files can also contain sensitive data, including cookies and session tokens, that malicious actors can use to impersonate valid users.” Okta’s response included “the revocation of embedded session tokens”, and its advice to everyone else was to sanitize “all credentials and cookies/session tokens within a HAR file before sharing it.”
A file attached to a case can be copied into a ticketing system, forwarded to an engineer, pasted into a chat channel when the engineer asks a colleague, and kept for as long as the case history is kept. Each of those places has its own accounts, its own admins and its own retention, and the customer who exported the file controls none of them. Okta’s production service was untouched, by its own account; the exposure came through the help desk.
Chrome’s sanitized default removes three headers, and tokens travel further
The What’s new in DevTools, Chrome 130 note announced that “the network log exported in HAR format will no longer contain Cookie, Set-Cookie, and Authorization headers by default.” The Network features reference describes the two export buttons that follow from it, “Export HAR (sanitized)” and “Export HAR (with sensitive data)”, and says the second needs Allow to generate HAR with sensitive data switched on in the Network preferences.
That default removes the headers where a browser sends its session cookies, and it is worth telling customers to use. It is also a list of three headers. A token can ride in a query string, as in a password-reset or magic sign-in link. It can sit in a custom header such as an API key. It can arrive in a JSON body, as the response to an OAuth token request does, or leave in a form body on the way to a login endpoint. None of those places is on the list the release note gives, and nothing in it says a sanitized export of a sign-in flow leaves out the password the form posted.
The default also stops at Chromium DevTools. Microsoft’s Network features reference for Edge documents the same Export HAR (sanitized) button and the same setting, so Chrome and Edge behave alike. Firefox’s Network Monitor toolbar documentation describes “Save All as HAR” and “Copy All as HAR” and documents no sanitizing option. A support macro that tells every customer to “export a HAR” can therefore get a different file depending on the browser, its version and whether somebody on the customer’s side once flipped a setting, and a customer on Firefox has no documented sanitizing step to follow.
A bug report needs the call and its status, not the payload
Line the contents of a HAR export up against what a developer reads when diagnosing a failed request, and most of the sensitive material sits in rows the diagnosis does not use.
| What a HAR export can carry | Where it sits in the file | What the bug report needs from it |
|---|---|---|
| Request URL and method | request | The path and method, to name the call that failed |
| Status code | response | Needed: it separates a server error from a missing resource or a refused session |
| Timings for each stage | timings | Useful when the complaint is that a page is slow |
Cookie and Authorization headers | request.headers, request.cookies | Not needed: the session belongs to the reporter, not to the defect |
Set-Cookie on responses | response.headers, response.cookies | Not needed, and it can be a newly issued session |
| Query string parameters | request.queryString | Rarely needed in full; a reset or sign-in link can put a token here |
| Posted form or JSON body | request.postData | Rarely needed; a sign-in form posts the password here |
| Response body | response.content.text | Needed only when the defect is in the data itself |
| Console errors | Not in the file | Needed, and they have to come from somewhere else |
The rows marked needed are short, and none of them is where a browser keeps a session. A console error beside them often explains more than the full trace would: a 500 on the save call next to an uncaught exception in the code that handled it narrows a client-side error to one function. Add the browser and the steps to reproduce, and a developer can usually rebuild the failure on their own account, where the cookies are theirs to lose.
The honest exception is the defect that lives in the payload: a 200 that returned the wrong price, a list missing one record, a field with an unexpected type. The status says nothing there. Even then the whole file is more than the case needs. Ask for the one field with everything around it redacted, which is PII masking done by hand, or reproduce on a test account whose responses hold nothing real. Bug reproduction on synthetic data takes longer than opening an attachment, and a session token in a ticket archive costs whatever someone else decides to do with it.
Notarus keeps the request and drops what it carried
Notarus answers the same question at the point of capture, before any export exists. The answer on the evidence capture page reads: “Network activity is recorded as the call and its result, never the payload, and authorization, cookie, password, token and secret are stripped from captured logs.” The same page says query strings are cut from every URL before it is stored and that IP addresses are kept salted-hashed. A report arrives with the request that failed and how it ended, next to the console output and the screenshot the reporter marked up, with no export attached for anyone to forward.
That design gives up exactly the exception above. When the defect is a wrong value inside a 200, a Notarus ticket shows a successful call and the reporter’s screenshot of the wrong number, and the developer still has to reproduce the response on an account of their own. The screenshot is the page as the reporter saw it, so anything visible on their screen can travel with it. And a report can still be sent without evidence, network log included, so a support team that relies on Notarus alone will sometimes still need to ask a question.
What it removes is the routine request for a file that can hold a working session. Where the status explains the failure, keeping only that much leaves the case history with the failing call in it instead of a copy of somebody’s signed-in session.
