Broken Object Level Authorization (BOLA)

A perfectly authenticated request can still be a completely unauthorized one. A user who is unquestionably who they say they are — valid token, valid signature, valid session — can still ask your API for `GET /invoices/8821` and receive someone else's invoice, simply because the endpoint checked that a token was valid and never checked that invoice 8821 actually belongs to the token's owner. That gap — authentication succeeding while the specific object being requested is never checked against the specific caller requesting it — is Broken Object Level Authorization, and it is the single most common serious vulnerability found in APIs in practice.

The reason it's so common is structural, not a matter of carelessness. Authentication is a one-time concern, checked once by a shared piece of middleware sitting in front of every route, and it's difficult to forget because the whole request pipeline depends on it working. Object-level authorization is the opposite: it has to be re-checked, correctly, on every single endpoint that accepts an object identifier, using logic specific to that endpoint's data model, and it is trivially easy to skip on any one of them and have nothing fail loudly. A codebase can have flawless authentication and a hundred correctly protected endpoints, and still ship one unprotected endpoint that hands out every other user's data to anyone who changes a number in the URL.

This lesson builds the mental model and the concrete pattern for closing that gap: every handler that receives an object ID from the caller — a path parameter, a query parameter, a field in a request body — must independently verify that the authenticated caller is entitled to that specific object, every single time, with no assumption that a valid-looking or hard-to-guess ID is itself a form of protection.

Because this is the highest-depth lesson in the course by design, it goes further than most: past the core pattern into where BOLA hides in list endpoints and nested resources, why sequential and UUID identifiers both fail to fix it on their own, and what a systematic, framework-level defence looks like rather than a per-endpoint patch applied one route at a time.

Analogy🏏Cricket

🏏 Think of it like cricket: A stadium's turnstile checks one thing and one thing only — is this a valid, scanned ticket for today's match? A steward standing just past the turnstile has an entirely separate job: does this specific ticket, now inside the ground, actually belong to this specific seat, in this specific stand, that the holder is now walking toward? A ground that nailed the turnstile check perfectly — no forged tickets get through, ever — but skipped the seat-block steward entirely would let every valid ticket-holder wander into any stand, sit in any seat, because being a genuine, validated ticket-holder was never the same question as being entitled to this specific seat. The turnstile is authentication: it establishes who you are. The seat-block steward is object-level authorization: it establishes whether you're entitled to this specific thing you're now trying to access. A ground can get the turnstile perfectly right and still lose control of the entire venue if it assumes a valid ticket at the gate is the same thing as a valid claim to every seat inside it.