Broken Object Level Authorization

What Is Broken Object Level Authorization?

Broken object level authorization, also called BOLA or IDOR, is the most common API vulnerability. The endpoint returns the object named by an identifier in the request without checking it belongs to the caller. The token is honest. You'll change a single number in a by-id URL, read a stranger's record, then walk sequential identifiers into a bulk harvest. The fix compares the record's owner against the authenticated session, and returns 404 rather than 403 so a rejected id cannot be confirmed to exist.

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

1. 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.

2. 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.

3. 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.

4. His trip, as expected

   The server returns exactly what it should: Bob's own trip, because the id he asked for is his.

5. 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.

6. Someone else's ride

   It answered. Bob's own rider token just pulled a trip that has nothing to do with him.

7. 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.

8. Every rider, at scale

   The ids run in sequence, and each one answers. That turns a single leak into a harvest.

9. Knowledge check

   You just watched a valid rider read strangers' trips by changing the id in the URL. Lock in why.

10. 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.