Test for broken access control
The worst bugs in an API are usually one user reaching another user's data. A scanner logged in as one identity cannot see them, because the response is a perfectly healthy 200.
Contents
Before you start
- Two accounts on the target with different privileges, or different data. One admin and one ordinary user works; two ordinary users who each own something works better.
- Endpoints in the asset graph, from a crawl or an import.
1Store one credential per identity
Add each account under Arsenal, then Credentials, exactly as in the previous tutorial, and label the role: admin, user-a, user-b. The labels are not decoration. They are how the result tells you which identity reached what it should not have.
You should seeTwo or more credentials, each with a role.
2Turn on authorization testing
Start a new vulnerability scan and switch on authorization testing. You get an identity matrix: a row per identity, each mapping a role to a credential. Add the anonymous identity too, because "no session at all" is the cheapest privilege level to test and the one that embarrasses people most.
You should seeA matrix with at least two rows, one per identity.
3Give it endpoints
The run needs at least two identities and at least one endpoint, because it works by comparison. Select the operations to test from the graph. Endpoints that take an object id in the path or the query are the ones worth prioritising.
You should seeThe launch button enabling once both conditions are met.
4Let it replay and diff
Every endpoint is sent as every identity and the responses are compared. What it looks for: user B retrieving user A's object by changing an id, a lower-privileged identity reaching a privileged action, fields a caller should not be able to set being accepted, and an endpoint returning more than the caller is entitled to. Coverage spans REST paths, query parameters and GraphQL.
You should seeCandidates confirmed by reproduction, not by a guess at the response.
5Read it as a diff
Each finding is a pair: this identity got this, and it should not have. Open it and check the two responses yourself before it goes anywhere. Where an application legitimately shares an object between accounts, this is where you see that, and it is a two-minute check rather than a retraction later.
You should seeThe privileged response, the unprivileged request that got it, and both identities named.
When it does not work
It found nothing with admin and user-a
Two identities at different privilege levels find BFLA. Two identities that each own different objects find BOLA, which is the more common bug. Give it both shapes if you can.
Is a 200 to the wrong identity always a bug?
No, and this is the class where confident wrong answers do the most damage. Shared objects, public resources and tenant-wide data all look identical from the outside. Confirm against what the application is supposed to do before you report it.
Which plan does this need?
Authorization testing unlocks on Pro and is enforced server-side, at launch and on every re-run.
Next: Keep a target monitored