What happened
In 2022 a major Australian telco, Optus, exposed the personal details of millions of customers. The cause was not a clever exploit. An API that returned customer data did not properly check who was asking.
Combine no authentication with identifiers you can count through, and pulling every record is just a loop.
How an open API leaks at scale
Broken access control is when an endpoint returns data without confirming the caller is allowed to see it. If the records are addressed by sequential IDs, an attacker increments the number and collects the lot.
It is the most common serious web flaw there is, and the least exciting. No memory tricks, no payloads. Just a door that was supposed to be locked and was not.
Why this keeps happening
Access control is easy to get wrong because the happy path works fine. The app behaves perfectly for a logged-in user clicking around. The flaw only shows when someone asks for a record that is not theirs, and nobody tested that.
Scanners that only read public pages never see it, because the endpoint looks like a normal API until you actually probe who it answers.
How it unfolded
- Sep 2022The breach becomes public. Millions of customer records are confirmed exposed.
- Late 2022Regulatory action and a national debate over data retention follow.
Where buggy.run fitsBroken access control hides behind a login you assume works. The only way to know is to sign in and check whether your endpoints actually enforce who can see what.
buggy.run signs in with real credentials, walks the authenticated surface, and tests whether an endpoint hands back data it should refuse, which is exactly the bug that hit Optus.
What to take away
- Authenticate and authorize every endpoint, including the ones that feel internal.
- Never rely on guessable IDs alone to protect a record.
- Test object-level access: can user A read user B's data?
- Rate-limit and monitor so enumeration stands out instead of blending in.
