The bug class scanners cannot see: BOLA, BFLA and BOPLA
Broken authorization sits at the top of the OWASP API list and template scanners are hopeless at it, because a valid request from the wrong person has nothing malformed to match on. Here is the testing model that does work.
Contents
The most common serious API bug is not injection and it is not a missing patch. It is one user reading another user's data, or a normal account calling something meant for admins. It is first on the OWASP API Security Top 10, and it is the class automated scanners are worst at.
The reason is simple once you see it. There is nothing wrong with the request. A perfectly valid, well-formed, correctly typed request from the wrong person is the vulnerability.
This sends real requests as real identities, so run it only against systems you own or have written permission to test. Poking at another user's access without that permission is not research.
Three names for one mistake
All three are the server trusting the caller more than it should.
- BOLA, object level. You ask for order 1043, order 1043 belongs to somebody else, and you get it anyway. The classic change-the-number bug.
- BFLA, function level. A regular account calls an admin action and the server just does it. The function was gated in the interface and nowhere else.
- BOPLA, property level. You send a field you should not control, like a role or a verified flag, and it sticks. Or the response hands you fields you were never meant to see.
Why a scanner walks straight past it
A template scanner asks whether a response matches a known-bad signature. A fuzzer asks whether malformed input breaks something. Authorization has neither a signature nor malformed input.
To know that this person should not have read that object, you have to know who they are, know the answer should have been no, and check whether it was. That needs identity and it needs comparison. Most tools carry neither, which is why they report a clean bill of health on an API that is leaking.
Replay as everyone, then compare
The approach that works is boring. Take each endpoint you have found and send the same request as several known identities, then look at what came back differently.
You want an admin as the privileged baseline, a normal user who owns some objects, a second normal user to probe across the boundary at the first one's objects, and nobody at all to catch endpoints that forgot to ask for credentials. When somebody low gets something they should not, that is your finding.
The subtlety that generates false positives: an admin reading a user's object is not a bug, it is the job. A test that flags every case where two identities can both see something will bury you. It has to know which direction crossing the boundary is wrong.
Confirm it before you report it
Authorization findings are valuable, which makes a false one expensive. Hand a client or a triager a broken one and you spend the rest of the engagement being doubted. So every authorization finding gets re-issued and checked that it reproduces before it reaches you. What lands is the set that held up, not a list of maybes for you to verify by hand on a Sunday.
How the identity matrix works in practice is on the vulnerability engine page, and the logins that feed it are covered in authenticated scanning. We also point this at ourselves, which is how we found an assistant that could read other people's data.
Point it at an API you are authorized to test and find out whether one user can reach another's data. Test an API