Check more than cookies.
Inspect request and response headers, cookie arrays, URL queries and fragments, request bodies, response text, redirects and custom extension fields. Account IDs or email addresses can appear in paths as well as bodies.
HAR exports from different tools can contain extra fields. A name-based secret filter cannot prove it has found every sensitive value.
Keep only what the recipient needs.
For many investigations, method, response status and timing are enough to establish the failure sequence. Retaining less information is easier to review than maintaining a growing blacklist of token names.
The Braith HAR sanitiser creates a minimal copy from a whitelist. It drops all headers, bodies, cookies, query values, fragments, path values and unknown fields. It retains origins, method, response status and numeric timings.
That loses detail on purpose. The output is useful for a request sequence, not for reproducing an authenticated request. Hostnames and timing can still identify an app or organisation.
Inspect the copy you will send.
Open the result with the HAR viewer. Search for known development sentinel values from the original file, and check that the diagnostic sequence is still understandable. Do not assume a “sanitised” filename establishes safety.
If credentials were already shared publicly, deleting a copy does not undo disclosure. Rotate the affected secrets through their provider and review access, rather than merely editing the recording.
Send the minimum reproduction.
Include the expected result, observed result, relevant request order and application version. Use a private support channel when the remaining hostname or context is sensitive. Keep the original off public issue trackers.
Reference: Chrome’s HAR export options. Browser sanitised export removes specific sensitive headers; it does not replace a review of the entire file.