Overview
API authorization testing — especially for broken object-level authorization — is the highest-value API testing area. This lesson covers it.
Learning objectives
- Explain API authorization testing.
- Focus on broken object-level authorization (BOLA).
- Test safely with the researcher's own accounts.
Core concept
API authorization testing verifies that authenticated callers can only access/act on what they're permitted — checking both object-level authorization (BOLA/IDOR — can a caller access another's objects by reference?) and function/role-level authorization (can a caller perform actions above their privilege?). BOLA is the top API risk (from the web-security API module) and the highest-value focus: APIs expose many object-referencing endpoints, and missing per-object checks let callers reach others' data. Testing uses the researcher's own test accounts to check whether authorization is properly enforced per object and per function.
How it works
Using the schema and the researcher's own test accounts (A and B, at various privilege levels), the researcher tests authorization on each endpoint: for object-level, can test user A access/modify test user B's object by changing the reference (BOLA)? — checked across all operations (read/update/delete), since enforcement is often inconsistent. For function/role-level, can a lower-privileged test account invoke a privileged endpoint? These reuse the authorization-testing techniques, applied systematically across the API's endpoints per the schema. Findings (BOLA, missing function-level authorization) are documented with reproduction (using the researcher's own accounts) and fixes (per-object and role checks). Testing never targets real users' objects.
Practical example
Testing an in-scope API with two test accounts, the researcher checks object-level authorization on GET/PUT/DELETE /api/orders/{id}: test user A can read their own order (fine) but can also delete test user B's order by changing the id — a BOLA flaw on the delete operation (missing per-object check). They document it (reproduction with their own test accounts, impact) and a fix (enforce per-object ownership on all operations). Systematic, per-operation authorization testing across the schema caught a high-value API finding, tested responsibly.
Cybersecurity relevance
API authorization — especially BOLA — is the highest-value API testing area, as BOLA is the top API risk (common, high-impact: mass access to others' data by iterating references) from the web-security API module. Systematic testing across the schema's endpoints and operations (with the researcher's own test accounts) finds these flaws; inconsistent enforcement (read but not delete, one endpoint but not another) is common. For defenders, the fix is per-object and role-level authorization on every endpoint/operation, default-deny. It reuses authorization-testing techniques at API scale. API authorization is where much bug bounty value lies.
Common mistakes
- Testing only some endpoints/operations, missing inconsistent authorization (e.g. delete not checked).
- Testing with real users' objects instead of the researcher's own test accounts.
- Focusing only on object-level and missing function/role-level authorization (or vice versa).
Key takeaways
- API authorization testing checks object-level (BOLA/IDOR — the top API risk) and function/role-level authorization across all endpoints and operations.
- Use the researcher's own test accounts (A/B, various privileges) to check per-object and per-function enforcement systematically per the schema — never real users' objects.
- Inconsistent enforcement is common (some operations/endpoints unchecked); fixes are per-object and role checks everywhere (default-deny) — the highest-value API testing area.
Check your understanding
- Why is broken object-level authorization (BOLA) the highest-value focus of API authorization testing?
- Why must object-level authorization be tested across all operations and endpoints, using the researcher's own test accounts?