> ## Documentation Index
> Fetch the complete documentation index at: https://qodex.ai/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# BOLA, IDOR, and BOPLA testing in Qodex

> Understand common authorization bugs and how Qodex checks them with multiple auth profiles. Compare the bug types and required test identities.

# 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`. |

BOLA and IDOR are closely related. BOPLA focuses on fields and properties, not just object ids.

## How Qodex tests BOLA and IDOR

Qodex needs at least two auth profiles, such as `userA` and `userB`.

The test shape is:

1. Authenticate as User A.
2. Create or read a resource and capture its id.
3. Switch to User B.
4. Request the same resource id as User B.
5. Expect the app to return `403` or `404`.

If the app returns `200` with User A's data, Qodex can open a security finding. Qodex also tries neighbouring ids and write actions (PUT and DELETE), and repeats the check across tenants and workspaces when your project has them.

## Qodex checks your rules first

Whether User B may see User A's order is a business rule, not something Qodex should guess. Before it calls any access a vulnerability, Qodex reads the rules you wrote in Knowledge, endpoint notes, and what you said in chat.

* If a rule forbids the access, the finding quotes that rule as its basis.
* If a rule allows it, nothing is filed, and the chat report lists it under **Ruled out by your rules**.
* If nothing covers it, Qodex asks you instead of filing, and the candidate waits on the Findings page as **Needs review**.

Write your access rules down (for example "a viewer can only read projects they belong to") to get findings instead of questions.

Severity follows reach: reading another tenant's records is high, while the same read between two workspaces of one tenant is medium.

## How Qodex tests BOPLA

For excessive data exposure, Qodex compares response fields against what the caller should see. Fields like `password_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

> [card] [OWASP API Top 10 in Qodex](https://qodex.ai/docs/security-testing-owasp-api-top-10.md)
>
> See where these bugs fit.

> [card] [Auth profiles](https://qodex.ai/docs/api-testing-auth-profiles.md)
>
> Configure multiple users and roles.

> [card] [Security scenarios](https://qodex.ai/docs/security-testing-scenarios.md)
>
> Save repeatable authorization checks.

> [card] [Inverted semantics](https://qodex.ai/docs/security-testing-inverted-semantics.md)
>
> Understand why blocked attacks pass.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.