What are BOLA, IDOR, and BOPLA, and how does Qodex test for them?
BOLA, IDOR, and BOPLA are authorization bugs. They happen when an API lets one user access an object, action, or field they should not be allowed to access.What the terms mean
| Term | Meaning | Example |
|---|---|---|
| BOLA | Broken Object Level Authorization | User B can read User A’s order by changing the order id. |
| IDOR | Insecure Direct Object Reference | Older name for object-id access bugs like BOLA. |
| BOPLA | Broken Object Property Level Authorization | A user can read hidden fields or write protected fields like role. |
How Qodex tests BOLA and IDOR
Qodex needs at least two auth profiles, such asuserA and userB.
The test shape is:
- Authenticate as User A.
- Create or read a resource and capture its id.
- Switch to User B.
- Request the same resource id as User B.
- Expect the app to return
403or404.
200 with User A’s data, Qodex can open a security finding.
How Qodex tests BOPLA
For excessive data exposure, Qodex compares response fields against what the caller should see. Fields likepassword_hash, private user data, internal ids, or admin-only values are suspicious.
For mass assignment, Qodex sends protected fields such as role: "admin" or isAdmin: true, then follows up to check whether the value persisted.
Why auth profiles matter
A single shared admin token cannot prove cross-user authorization. Create separate auth profiles for roles such as admin, user, viewer, and another normal user. Qodex uses those profiles to test whether permissions are enforced across real role boundaries.Next steps
OWASP API Top 10 in Qodex
See where these bugs fit.
Auth profiles
Configure multiple users and roles.
Security scenarios
Save repeatable authorization checks.
Inverted semantics
Understand why blocked attacks pass.