Broken object-level authorisation is rarely just an id=1002 problem. In a mature API assessment, the important question is whether the server consistently derives authorisation from the authenticated principal, the object, the tenant and the requested action. OWASP identifies Broken Object Level Authorization as API1:2023 and recommends considering object-level checks in every function that uses a client-supplied object identifier. OWASP API Security Top 10.
1. Model the authorisation boundary
Start by mapping principals, tenants, objects and actions. A useful model is subject → action → object → tenant → policy. For each API family, identify which fields are security-sensitive and whether the server can derive them independently.
| Dimension | Questions | Evidence |
|---|---|---|
| Subject | Which user, service or role is authenticated? | Token/session context |
| Object | Who owns the resource? | Object metadata |
| Tenant | Which organisation contains it? | Tenant mapping |
| Action | Is read different from update/delete? | HTTP method + endpoint |
2. Build an object map
Capture identifiers from URLs, JSON bodies, nested resources, GraphQL variables, filters and export endpoints. UUIDs and opaque IDs reduce casual guessing but do not replace authorisation. The test is whether a principal can access an object they are not entitled to access.
Keyboard: ← → · Respects reduced-motion (no autoplay).
Authorisation decision simulator
Select the context to see what a secure server should do.
3. Look for chains, not isolated requests
A low-privileged read may become more serious when combined with update, export, password-reset, invite or administrative endpoints. Test the same object across GET, PATCH, DELETE, bulk endpoints and nested resources. Then compare behaviour across roles and tenants.
GET /api/accounts/1002 PATCH /api/accounts/1002 DELETE /api/accounts/1002 POST /api/accounts/1002/export
For GraphQL, repeat the exercise with node IDs, resolver arguments, nested relationships and mutations. The objective is to identify inconsistent enforcement between resolvers.
4. Measure impact
Record the minimum privilege required, number and type of affected objects, whether the issue crosses a tenant boundary, and whether write actions are possible. Avoid broad extraction: demonstrate the smallest amount of data or state change needed to prove the boundary failure.
5. Defensive design
Centralise authorisation decisions where practical, enforce ownership or tenant constraints server-side, and test authorisation at the service layer rather than trusting client-supplied tenant or owner fields. Add automated authorisation tests for each sensitive object type and action.
Pentest checklist
- Map object identifiers and ownership.
- Build a role × action × object matrix.
- Test read, write, delete and export paths.
- Repeat across tenants and nested resources.
- Check bulk and batch endpoints.
- Check GraphQL queries and mutations.
- Document the smallest reproducible proof.
Related research: BOLA testing methodology · Fintech API authorisation case study.
Frequently asked questions
What is an API authorisation attack chain?
A sequence that starts with an object- or function-level access failure and ends in broader tenant or privilege impact—validated under agreed rules of engagement.
How is this different from a single BOLA finding?
BOLA is often one edge. A chain shows how that edge combines with other gaps (listing, mass assignment, admin functions) to change business impact.
Do scanners find these chains reliably?
Automated tools help discovery. Chaining and tenant-impact judgment usually need manual testing with realistic roles.
What evidence should buyers expect?
Role matrices, reproducible requests and a clear statement of which tenant or privilege boundary failed.
