This program doesn't disclose reports so unfortunately I'll have to keep everything anonymous. I'll do my best to go in-depth while staying within the NDA.

How It Began...

I wish I could say there was some beautiful story behind this bug, but truth be told sometimes you just find a numeric IDOR on the frontpage of one of the biggest public programs on the internet.

So I was doing my usual recon dance—clicking through the UI, letting jxscout (seriously, 10/10 tool, go grab it) suck down every bit of JavaScript it could find. I flipped over to Burp Suite to review the login flow when something jumped out at me: a request that just felt off. Right there in the parameters was a plain, unhashed and unencoded accountNumber. 

This required immediate probing... **pulls out latex gloves**

Exploitation

I popped in my test account's info fully expecting to meet a wall as usual but nope. I swapped in my own account number, fired off the request, and it came back with exactly what it shouldn’t have: my test account number plus all the associated phone numbers tied to it.

The endpoint didn’t care about session cookies or any kind of authentication. You could hit it cold with a simple GET request and still get the goods.

Final Thoughts

Classic IDORs are far from dead, folks. They’re just hiding in plain sight on APIs that everyone forgot to double-check. Big companies with massive attack surfaces still ship stuff like this, and that’s exactly why bug hunters keep eating.

Got paid a solid $3K for the find, the program improved their security posture, and I walked away with another fun story (and another reminder to never trust a plain numeric ID). Win-win.

Stay curious, keep testing, and remember: if it looks too simple to be vulnerable… it probably isn’t. 😉