A browser export nearly made us report a leak that was not there
A scanner that reads a capture can be wrong about who was logged in. We nearly filed a finding built on that.
We were testing a clinical documentation app: a React front end with Firebase sign-in, in a regulated health setting. The capture we were given had been taken while fully logged in. Our tool read it as anonymous traffic.
The capture that lost its login
A test of a logged-in app starts from a browser capture, a HAR file, of a real session. Ours had been exported from Chrome, and Chrome's exporter had removed the authorisation header from every request.
Our toolkit's parser looked for a cookie or an authorisation header, found neither, and wrote down that only unauthenticated endpoints would be tested.
How close it came
The traffic in that capture was patient-shaped data returned on protected paths. Read as anonymous, that is an unauthenticated exposure of health data, which is the most serious thing a report in this sector can say.
We nearly wrote it. Verification retracted it: a protected path answering an anonymous caller with a normal page was the clue that the caller had never been anonymous.
What the real review found
Reading the shipped JavaScript showed what a plain scanner does not look for: 15 public source-map files carrying the full source of the front end, and a message handler that relays a sign-in token with no check on who sent the message and replies to any origin.
Cross-tenant access, path traversal, token forgery, SQL injection and privilege escalation were each tested and ruled out. For the public source maps we added a negative control: a made-up map path returned 404, which proved the 200 answers were real.
What we changed in the tool
The parser no longer asserts that traffic is unauthenticated when the capture looks authenticated. It checks four signals: a referring page inside the app, personal-data-shaped fields in a response, a successful answer on a protected path, and a known sign-in provider host. If any one is present it warns that headers may have been stripped and asks for a fresh capture.
A capture with none of those signals keeps the old message. When the login state is unclear, the tool now picks the answer that cannot produce a false leak.
What to take from it
- Check the input before you trust the verdict. A tool can be right about the data it saw and wrong about the session.
- Ask what else would explain a surprising result. A normal answer to an anonymous caller was the clue.
- Prove a finding with a control. The bogus path that returned 404 is what made the real 200 answers believable.
Want your security findings checked for false alarms?
We try to disprove a finding before we report it. The first month is a trial.
