Home / Knowledge hub / BOLA
Knowledge hub
BOLA
An API returns a record just because you asked for it by number.
What it means
BOLA stands for broken object level authorization. An API hands back a record because you asked for it by number, without checking the record is yours.
The whole exploit is changing one digit. Ask for order 1041 instead of order 1040 and read a stranger's order. No payload, no malformed input, nothing that looks like an attack in any log you keep.
Why it matters
It is the most common serious API flaw and among the easiest to prove, which is an uncomfortable pairing. It is also silent. Every request authenticates correctly and gets a normal answer. The first sign is usually a customer spotting somebody else's details on their own screen.
Scale makes it expensive. A flaw that returns one record returns all of them, because the only work involved is counting. Nothing separates a curious customer from a full copy of your data until somebody looks at volumes.
Unguessable identifiers do not fix it. A random string slows somebody down, but every place your product legitimately shows an identifier hands an attacker a supply of them.
How it shows up
Look for any endpoint that takes an identifier and returns something belonging to one customer: invoices, orders, files, messages, reports, uploaded documents. Then ask whether the check is 'is this caller logged in' or 'does this record belong to this caller'. Only the second is authorisation.
Check writes as well as reads. Reading somebody else's invoice is bad. Updating or deleting it is worse, and both usually sit behind the same missing check.
Proving it takes two real accounts and a request from one aimed at the other's data. See how we test it.
Questions people ask
BOLA, answered
How is BOLA different from broken access control?
Broken access control is the family. BOLA is one member of it, the one where an API hands back an object because you named it, without checking the object is yours.
IDOR is the older name for the same idea. When one report says IDOR and another says BOLA, they usually mean the same request returning the same stranger's record.
Should our order numbers be guessable?
Ideally not, and that is a separate problem from this one. Sequential numbers tell an outsider how many orders you take, and they make counting trivial.
Fix the check first. An unguessable number with no ownership check is still a leak, because every invoice, email and support ticket hands out real identifiers all day.
If we switch to random identifiers, are we safe?
No. You have made guessing slower. You have not made the check exist. Anybody who was ever given a valid identifier still works, including a former customer, a contractor or a partner.
Treat random identifiers as good hygiene. Treat the ownership check on the server as the actual control.
Does it count if the record is not sensitive?
It counts, and the severity follows the record. Reading somebody else's profile photo is a bug. Reading their invoice is a conversation with your customers.
Be careful about ruling a record harmless. Names, email addresses and order histories look dull on their own and identify a person the moment you combine them.
How do we actually prevent this in our API?
Check ownership on the server for every request that names an object, using the identity in the session rather than anything sent with the request. Scope the database query to that owner instead of fetching the record first and filtering afterwards.
Then test it with two accounts. A missing check looks identical to a working one until somebody aims one account at the other's data.
Related
Terms that sit next to this one
IDOR
Changing an id in a request and getting back someone else's record.
Broken access control
An application failing to enforce its own rules about who may do what.
API
The part of your application other software talks to, not a person.
Authorization
Deciding what a proven user is then allowed to do.
Tenant isolation
What keeps one customer's data unreachable from another's session.
One digit from another account?
We run two real accounts against each other, endpoint by endpoint, and report only what genuinely returned somebody else's record. Thirty days on one application costs $199.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.