Home / Knowledge hub / Object-level authorisation
Knowledge hub
Object-level authorisation
Checking access to each individual record, not only to the type of record.
What it means
Object-level authorisation is the check that an account may use this particular record, not just records of this kind. Being allowed to view orders is a function-level permission. Being allowed to view order 1042, because it is yours or your team's, is object-level.
Every request that carries an identifier needs it, whatever the method. The identifier may sit in the path, the query string, the body or a header. Wherever it comes from, the server has to compare it with the signed-in account before touching the record.
Why it matters
Its absence is the most common serious flaw in APIs. OWASP puts broken object-level authorisation first in its API Security Top 10, because it is easy to introduce and ordinary requests are enough to exploit it. No clever payload is needed, only a different number.
The business cost is customer data reaching the wrong customer. That means breach notices, contractual penalties and lost deals. Because each request looks normal, your logs may show nothing unusual, so the first you hear of it is a customer or a researcher.
How it shows up
Look at every endpoint that takes an identifier, including the ones the web app never calls. The check belongs on the server, in a shared layer where it is applied to reads, updates and deletes alike. This flaw is also known as BOLA, and in older web apps as IDOR.
Typical gaps: the list endpoint filters by owner but the single-record endpoint does not; the update checks ownership but the export does not; bulk calls check only the first item. A good test uses two ordinary accounts and swaps identifiers between them. See ownership check for the pattern.
Questions people ask
Object-level authorisation, answered
What is the difference between object-level and function-level authorisation?
Function-level asks whether an account may use an operation at all, such as exporting reports. Object-level asks whether it may use it on this specific record.
You need both. See BFLA for the function-level failure.
Is object-level authorisation the same as BOLA?
BOLA is the name of the flaw when it is missing. Object-level authorisation is the control that prevents it.
OWASP's API Security Top 10 uses the flaw name, Broken Object Level Authorization, for its first entry.
Do UUIDs make the check unnecessary?
No. Random identifiers are harder to guess, but they appear in links, emails and logs, and anyone who obtains one can use it.
Treat them as a minor extra layer, never a substitute for the check.
Where should the check be implemented?
On the server, in a layer every route passes through, so it cannot be forgotten in one handler. Policy libraries and query scoping both work.
Do not rely on the front end hiding a button. The caller can send the request directly.
How do we test for it?
Take two ordinary accounts. Capture a request from the first, then replay it with an identifier owned by the second and see whether the data or the change goes through.
Repeat for every method and every route that takes an identifier.
Related
Terms that sit next to this one
BOLA
An API returns a record just because you asked for it by number.
IDOR
Changing an id in a request and getting back someone else's record.
Ownership check
Confirming that the record being requested belongs to the account asking for it.
BFLA
An API lets an ordinary account call functions meant only for admins.
Cross-account access
One signed-in account reaching another account's data or functions.
Is every record checked, or just the list?
Object-level gaps are the cross-account access we look for first: one signed-in account reading or changing another's records. Each finding includes the request and response that proved it. Book a pilot on one app.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.