How Safe Is the Login Button, Really

Everyone worries about the dramatic vulnerabilities. The injection, the remote code execution, the movie-hacker stuff. Meanwhile the bug that quietly leaks the most real data is almost boring: you are allowed to ask for your own order, number 1043, and nobody ever checked what happens when you ask for number 1042.

That is IDOR, insecure direct object reference, and it is one of my favourite bugs precisely because it is so unglamorous.

The whole class comes down to a single missing question. The app correctly checks “are you logged in?” It forgets to check “are you allowed to see this specific thing?” Authentication without authorization. It knows who you are. It just never confirms that who you are has any business looking at what you asked for. So you change a number in a URL, or an ID in an API request, and the server hands you someone else’s invoice with a smile.

The API version has a name too (BOLA, broken object level authorization), and it sits near the top of the OWASP API list for the very good reason that modern apps are mostly APIs now, and APIs love to trust an ID.

The tool I reach for here replays a request across two sessions, two different users, and diffs the responses. If user A can pull user B’s data by changing an identifier, the diff lights up. Deeply unglamorous. It found the gap immediately on crAPI, which is exactly the kind of deliberately broken target you are allowed to point it at.

So, how safe is the login button? The login button is fine. It is everything after the login button that nobody guards. The app checks your ID at the door and then lets you walk into the vault. My job is to be the person who tries the vault.