Authentication tells you who someone is. Authorisation tells you what they're allowed to do. The two get conflated constantly, and the gap between them is where most of our high-severity API findings come from.
Why authentication isn't authorisation
A valid token or session cookie proves identity. It says nothing about whether that identity should be able to view invoice #4821, delete another team's project, or call an admin-only endpoint. An API can have flawless authentication — properly signed tokens, short expiry, MFA on login — and still leak every customer's data to every other customer, because nothing on the server checks ownership before returning the record.
Common patterns we see in the wild
The most frequent version is straightforward object-ID enumeration: increment a numeric ID in the URL, get back someone else's data. Slightly less obvious is function-level authorisation — a regular user calling an endpoint that was only ever meant to be reachable from the admin panel, because the endpoint itself never checks the caller's role. Both are trivial to exploit once found, and both routinely slip past automated scanning because the request looks entirely legitimate.
How we test for it
This is inherently manual work. We map out every role and tenant boundary the application is supposed to enforce, then systematically try to cross those boundaries — viewing another user's data, calling another role's endpoints, acting across tenants. A scanner can tell you an endpoint exists and returns a 200. It can't tell you that the 200 shouldn't have happened for that particular user.
The most dangerous authorisation flaws don't look like attacks. They look like a normal, valid request — for the wrong resource.
If your last security review focused on authentication — SSO, MFA, token handling — and didn't specifically test authorisation boundaries between users, roles and tenants, there's a good chance this is where your next finding is waiting.