Broken Object Level Authorization
A valid rider swaps the id in a GET /trips/{id} call to one that isn't theirs and the server answers, because it checks the session but never that the trip is theirs. Sequential ids let you harvest every rider, then you ship the ownership check.
What Is Broken Object Level Authorization?
Broken object level authorization (OWASP API1:2023), often called BOLA or IDOR, is the most common API vulnerability: an API validates that a caller holds a valid session and then returns the object named by an identifier in the request, without checking that the object belongs to that caller. The classic shape: a by-id read like GET /resource/{id} is available to every authenticated user for their own records, the id is fully attacker-controlled, and the handler loads the object and returns it with no ownership comparison, so any valid session reads any id. It is distinct from broken function level authorization, where the caller's role is not permitted to invoke a function at all, and from a token-forging privilege escalation, where the attacker tampers with their own credential; here the token is honest, the endpoint is one the caller is allowed to use, and the missing check is whether the specific object is theirs. This exercise puts you on both sides. As Bob, a genuine rider on Larkway's ride-hailing app using its personal trip-export API, you first fetch one of your own trips by id, then change a single number in the URL and read a stranger's receipt, name, home pickup, destination, and travel time, and because the ids run in sequence you walk them to harvest every rider's movements, all returning 200. As Alice, the backend engineer who owns the Trips API, you open the handler on the receiving end of a monitoring alert, see that it loads the trip straight from the URL id and never scopes it to the caller, and ship the fix: compare the trip's owner to the identity from the authenticated session and, on a mismatch, return the same 404 a missing id gets so a rejected id cannot even be confirmed to exist. The exercise closes with quiz questions on the authentication-versus-authorization distinction, why a role guard cannot fix an object-level gap, why unguessable ids are not access control, where the caller's identity must come from, and why 404 beats 403 for closing the enumeration oracle.
What You'll Learn in Broken Object Level Authorization
- Recognize broken object level authorization: a valid session reading another user's object because the endpoint checks who is calling but not whether the returned record belongs to them
- Distinguish it from broken function level authorization (a role reaching a function it may not call) and from token-forging privilege escalation (tampering with your own credential); here the token is honest, the endpoint is allowed, and the object check is missing
- See how sequential or guessable object ids turn a single unauthorized read into a full enumeration, and why unguessable ids reduce that risk but are not access control
- Apply the fix: after loading an object, compare its owner to the identity from the authenticated session rather than anything the caller sends, and refuse when they do not match
- Prefer a not-found over a forbidden on a rejected object so a denied id is indistinguishable from a missing one, closing the existence oracle, and audit every by-id read for the same gap
Broken Object Level Authorization — Training Steps
-
An ordinary rider
Larkway is a ride-hailing app, and it lets any rider turn on a personal Trips API to export their own ride receipts for expense reports. Bob signed up as a normal rider, with a throwaway identity, and switched it on. His account is nothing special: a plain rider seat with a token that reads his own trips. He opens the developer console to see what the API gives him.
-
Trip ids are just numbers
Bob's own trips are listed with their ids, and the API reference shows how to fetch any single trip receipt by its id. Two things stand out about those ids.
-
Fetch his own trip
First Bob calls the endpoint the way it is meant to be used: he asks for one of his own trips by its id, carrying his own rider token in an Authorization header, exactly as the app does.
-
His trip, as expected
The server returns exactly what it should: Bob's own trip, because the id he asked for is his.
-
Change one number
Bob sends the same request, carrying the same token, and changes only the id, one below his own. If the server checks that a trip belongs to the caller, this should return nothing. If it only checks that his session is valid, it will answer.
-
Someone else's ride
It answered. Bob's own rider token just pulled a trip that has nothing to do with him.
-
Walk the sequence
One stranger is a curiosity. Bob keeps decrementing the id, and every value returns a real receipt. He reaches for another one to confirm the pattern.
-
Every rider, at scale
The ids run in sequence, and each one answers. That turns a single leak into a harvest.
-
Knowledge check
You just watched a valid rider read strangers' trips by changing the id in the URL. Lock in why.
-
The alert lands
You own Larkway's rider-facing Trips API. Overnight, monitoring flagged one rider token pulling thousands of trips that were not its own. Security operations has emailed you the details.