Broken object level authorisation sits at the top of the OWASP API Security Top Ten for good reason. The flaw is simple, the consequences are severe and the bug remains depressingly common across modern APIs. A user authenticates legitimately and then asks the API for a record using its identifier. The API returns the record without verifying that the caller is allowed to see it. Multiply that across hundreds of endpoints and millions of records, and you have a quiet route to bulk data theft.
Why The Bug Survives
Object level authorisation often gets lost between teams. The framework handles authentication. The infrastructure handles transport security. The application developer assumes someone else is handling per-record access. The same developer would never forget to check authentication, because authentication is centrally enforced. Per-object checks have to be written for each endpoint, by hand, and the consistency tends to drift over time. A focused web application pen testing engagement should pair endpoints in test cases and verify that a user cannot access another user records through any route.
Identifiers Are Easy To Guess
Sequential numeric identifiers make exploitation trivial. UUIDs make enumeration harder but do not solve the underlying problem, because identifiers leak through related endpoints, exported reports and search functions. Treat the identifier as public information, because it almost always becomes public in practice. The defence is the authorisation check on the server, not obscurity of the identifier.
Expert Commentary
William Fieldhouse, Director of Aardwolf Security Ltd
The pattern we see most often is an endpoint that checks ownership for direct access but skips the check on a related action. A user can view their own invoice with proper authorisation. The same user can download a PDF of any invoice by changing the identifier in the export endpoint. Both endpoints needed the same check. One got it.
Test Cases That Catch The Pattern
Building object level authorisation testing into your continuous integration pipeline catches the gaps before they ship. The tests do not have to be exotic. Provision two test users, have one of them create a record, then attempt every endpoint that takes that record identifier as the other user. Failures are findings. Successes are confirmations. The discipline is operational rather than technical, which is why it works as long as somebody owns it. The teams that catch this class of bug consistently treat object level checks as a non-negotiable part of every endpoint pull request. The discipline scales because it is built into the development culture rather than imposed at the security review stage.
Build It Once, Apply It Everywhere
The sustainable answer is to centralise object access checks rather than scattering them across hundreds of controllers. A policy engine that the entire codebase calls is far easier to verify than a check that has to be remembered in every handler. Pair the central policy with a structured vulnerability scan services programme so the gaps that do appear get found before an attacker exploits them at scale.
Object level authorisation is unglamorous engineering. It is also the difference between a slightly leaky API and a data breach. Object level authorisation is the unloved corner of API security and the corner where most of the serious breaches actually originate. Worth the attention. API security is harder than web application security in some respects and easier in others. The teams that understand the differences and design their controls accordingly tend to produce better outcomes than the ones that simply apply web thinking to API problems.
