Authentication versus authorization
Two different questions that get merged into one word and cause real breaches.
Authentication asks "who are you?". Authorization asks "are you allowed to do this?". They are separate questions, answered at different moments, and confusing them is one of the most common serious bugs in small applications.
The discipline is that every request touching a specific record asks two questions, not one. Are you logged in, and is this particular record yours to see? The second check has to happen on the server, next to the data, every single time, not once at login, and not in the frontend.
If I change the id in this URL, do I see someone else’s data?
It takes ten seconds to test and it is the single highest-value security check a non-engineer can perform on their own app.
What to remember
- Authentication is identity; authorization is permission.
- Logged in does not mean allowed. Check ownership per record.
- Changing an id in the URL is the test everyone should run.
Terms in this lesson
Field notes
Loaded from a deliberately slow source. The lesson above was already readable while this was still travelling. That is streaming, and it is the same trick a chat interface uses.
The URL that read everyone’s invoices
An invoice page checked that you were logged in and then loaded whatever id was in the address. Changing the number showed somebody else’s invoice. It was found by a customer who mistyped, not by a review.
Classic IDOR, still extremely common
The key in the client bundle
An API key was placed behind the public environment prefix so it would be readable from the frontend. It worked. It was also visible to every visitor, and was being used by strangers within a week.
Scraped from a public bundle
resolved in 901ms · region iad1
Hide field notes toggles a search param the loader reads. With it off, the slow promise is never created, so nothing streams.