A 97 MB capture, and why we score findings as chains

An export too big to read

The browser's own export of a long session was 97 MB and cut off before the end. A tool that reads it as one file fails or gives up.

We recovered 1,394 requests from the part that survived and grouped them into 108 endpoint templates, so the testing started from the app's real traffic rather than a guess at its routes.

What held

Isolation between organisations held: another organisation's data answered 403, and another organisation's project answered 404. The token-signing secret could not be cracked, and a token with its signature switched off was rejected.

Because the agreement was read-only, write paths were out of scope. The report says so.

What did not

There was no limit on login attempts, and the response time gave away which usernames existed. The authenticated API allowed requests from any website, and the pages carried no content-security policy or integrity checks.

Each of those alone looked minor. Two of them chain into an account takeover and token theft path.

Why we score chains

A list of findings ranked one by one makes a chain look like three small problems. We score the combination: what an attacker can do with the findings together.

The final report had 13 findings with none critical or high, four medium, six low and three informational, and 12 of them were filed for the team to work.

What to take from it

• Do not let a bad input stop the work. Recover what you can and say what you recovered.
• Report what held. It is as useful as what broke.
• Score the chain. Findings combine, so the ranking should too.