Post cover image

September 3, 2026

IDOR to BOLA — Mastering Authorization Bugs in Bug Bounty

From Simple ID Manipulation to Advanced Authorization Testing

By mahfujwhh

7 min read

From Simple ID Manipulation to Advanced Authorization Testing

One of the first vulnerabilities many bug bounty hunters learn is IDOR.

It looks simple:

GET /api/users/1001

Change:

1001 → 1002

And suddenly you see another user's information.

But that's only the beginning.

Modern authorization vulnerabilities are much broader than simply changing an ID.

They can involve:

  • Users
  • Organizations
  • Teams
  • Projects
  • Invoices
  • Orders
  • Files
  • API keys
  • Roles
  • Permissions
  • Tenants
  • Administrative functions

And this is where IDOR evolves into BOLA, BFLA, privilege escalation, cross-tenant access, and complex authorization flaws.

This article explains how to go from understanding basic IDOR to developing an advanced authorization-testing methodology.

Table of Contents

  1. What Is Authorization?
  2. Authentication vs Authorization
  3. What Is IDOR?
  4. A Simple IDOR Example
  5. Horizontal Privilege Escalation
  6. Vertical Privilege Escalation
  7. IDOR in APIs
  8. What Is BOLA?
  9. IDOR vs BOLA
  10. BFLA
  11. Nested Object Authorization
  12. Cross-Account Authorization
  13. Cross-Tenant Authorization
  14. Authorization in Different HTTP Methods
  15. Authorization Beyond IDs
  16. Advanced Authorization Testing
  17. How to Test Authorization Systematically
  18. Multiple-Account Testing
  19. Business Logic + Authorization
  20. Common False Positives
  21. Impact
  22. Authorization Testing Checklist

1. What Is Authorization?

Authorization is the process of deciding:

What is this authenticated user allowed to access or perform?

Imagine an application has:

User A
   ↓
Project A
User B
   ↓
Project B

The application must enforce:

User A → Project A ✓
User A → Project B ✗

If the server fails to enforce that boundary, we may have an authorization vulnerability.

             APPLICATION
                   │
          ┌────────┴────────┐
          ▼                 ▼
       User A             User B
          │                 │
          ▼                 ▼
     Project A          Project B
          │                 │
          └───────X─────────┘
          Authorization
             Boundary

The key point:

Authorization must be enforced by the server.

A frontend button being hidden is not authorization.

2. Authentication vs Authorization

These two concepts are frequently confused.

Authentication

Answers:

Who are you?

Example:

Username+Password= Authenticated User

Authorization

Answers:

What are you allowed to do?

For example:

Authenticated User
       ↓
Regular User
       ↓
Can view own invoices
       ↓
Cannot view other users' invoices
       ↓
Cannot access admin functions

[Authentication vs Authorization]

AUTHENTICATION
       │
       ▼
   WHO ARE YOU?
       │
       ▼
    Logged In
       │
       ▼
AUTHORIZATION
       │
       ▼
WHAT CAN YOU DO?

A user being authenticated does not mean they are authorized to access everything.

3. What Is IDOR?

IDOR stands for:

Insecure Direct Object Reference

The basic idea is simple. An application exposes a direct reference to an object:

GET /api/invoices/1001

The server should verify:

Does invoice 1001 belong to this user?

If it simply retrieves the object:

invoice = database.find(1001)

without checking ownership, the application may be vulnerable.

4. A Simple IDOR Example

Imagine two accounts:

Account A
User ID: 101
Account B
User ID: 202

Account A creates:

Invoice ID: 5001

Account B creates:

Invoice ID: 5002

Account A sends:

GET /api/invoices/5001
Authorization: Bearer USER_A_TOKEN

Response:

{
  "id": 5001,
  "owner": 101,
  "amount": 500
}

Now, in an authorized test environment, the researcher checks:

GET /api/invoices/5002
Authorization: Bearer USER_A_TOKEN

If the server returns Account B's invoice, the important observation is:

Authenticated as A
        ↓
Requested B's object
        ↓
Server returned B's object
        ↓
Ownership check failed

That is the essence of object-level authorization failure.

[ IDOR flow]

USER A TOKEN
     │
     ▼
/api/invoices/5002
     │
     ▼
Server
     │
     ├── Is invoice 5002 owned by A?
     │
     └── ❌ No ownership check
              │
              ▼
        Invoice B returned

5. Horizontal Privilege Escalation

Horizontal access means:

One user accesses another user's resources at the same privilege level.

Example:

User A
   ↓
Own profile ✓
User A
   ↓
User B profile ✗

Both users are regular users and same role.

Therefore:

Same privilege+Different object = Horizontal authorization issue

Common targets include:

  • Profiles
  • Orders
  • Invoices
  • Documents
  • Messages
  • Tickets
  • Projects
  • API keys
  • Payment records

6. Vertical Privilege Escalation

Vertical privilege escalation is different.

Here the attacker moves from a lower privilege level to a higher privilege level.

For example:

Regular User
      ↓
Admin Function or higher user

Imagine:

POST /api/admin/users/123/disable

A normal user should receive:

403 Forbidden

If the server performs the administrative action instead, the issue is much more serious.

[ Horizontal vs Vertical]

PRIVILEGE
                    ▲
                    │
              Admin │
                    │
                    │   ↑ Vertical
                    │
              User  │
                    │
                    └──────────────► Objects
                       Horizontal

7. IDOR in APIs

Modern IDOR vulnerabilities frequently appear inside APIs.

For example:

GET /api/v1/users/123

or:

GET /api/v1/orders/9876

or:

GET /api/v1/projects/456

or:

GET /api/v1/documents/321

The identifier may be:

Integer
UUID
Encoded value
Slug
Filename
Reference number
Database key

Don't assume:

"It's a UUID, so it isn't vulnerable."

Predictability is not the requirement. and can find uuid using recon (web archive, virustotal, usrlsacn etc)

Authorization failure is the requirement.

8. What Is BOLA?

BOLA stands for:

Broken Object Level Authorization

It is an API security problem where the API fails to properly verify whether the authenticated user is authorized to access or manipulate a specific object.

For example:

User A
   ↓
GET /api/orders/order-A

works correctly.

But:

User A
   ↓
GET /api/orders/order-B

also works even though Order B belongs to User B.

That's a BOLA scenario.

9. IDOR vs BOLA

These concepts overlap, but they aren't exactly the same terminology.

IDOR

Traditionally describes insecure direct references to objects.

BOLA

Is the API-security terminology emphasizing failure to enforce authorization at the object level.

Think of it like:

IDOR
 │
 ├── Web applications
 └── APIs
BOLA
 │
 └── API object authorization

A useful mindset is:

Don't focus on the acronym. Focus on the authorization decision.

10. BFLA

BFLA means:

Broken Function Level Authorization

BOLA asks:

Can I access someone else's object?

BFLA asks:

Can I execute a function I shouldn't be allowed to execute?

For example:

POST /api/admin/users/123/delete

A regular user should not be able to perform this function.

The server should enforce:

User
 ↓
Role = user
 ↓
Admin function?
 ↓
NO
 ↓
403

If the function executes anyway, that's a function-level authorization problem.

11. Nested Object Authorization

This is where authorization testing becomes more interesting.

Consider:

Organization
   └── Project
        └── Invoice
             └── Payment

An application may correctly protect the top-level object but fail to protect a nested object.

For example:

GET /api/organizations/A/projects/123/invoices/456

A researcher should think:

Does the user have access to:
Organization A?
Project 123?
Invoice 456?

Authorization should be checked across the entire object hierarchy.

[ Nested authorization]

Organization
      │
      ▼
   Project
      │
      ▼
   Invoice
      │
      ▼
   Payment
Every layer needs authorization.

12. Cross-Account Authorization

Many applications allow users to interact with other users.

Examples:

Invite
Share
Transfer
Collaborate
Assign
Mention
Send
Export
Download

These workflows create interesting authorization boundaries.

Example:

Account A
   ↓
Creates Project
   ↓
Invites Account B

Now ask:

What happens if Account B attempts to access objects that belong only to Account A?

Or:

What happens after Account B is removed?

Authorization must remain correct throughout the object's lifecycle.

13. Cross-Tenant Authorization

This is especially important in SaaS applications.

Imagine:

Tenant A
 ├── User A1
 ├── User A2
 └── Projects
Tenant B
 ├── User B1
 ├── User B2
 └── Projects

The application must enforce:

Tenant A ≠ Tenant B

A cross-tenant authorization issue can be significantly more serious because one customer may access another customer's data.

[ Multi-tenant isolation]

SaaS APPLICATION
                    │
          ┌─────────┴─────────┐
          ▼                   ▼
      TENANT A             TENANT B
          │                   │
       Users                 Users
       Projects              Projects
       Invoices              Invoices
          │                   │
          └────────X──────────┘
              Isolation

14. Authorization Across HTTP Methods

Don't test only GET.

An object might be protected for reading but improperly protected for modification.

Test the application's intended methods in an authorized lab or program:

GET
POST
PUT
PATCH
DELETE

For example:

GET /api/project/123
PATCH /api/project/123
DELETE /api/project/123

Ask:

Can I read it?
Can I modify it?
Can I delete it?
Can I perform an action on it?

Different functions may have different authorization controls.

15. Authorization Beyond IDs

A common beginner mistake is thinking:

"IDOR means changing an ID."

That's too narrow.

Object references can appear in:

Path
Query parameter
JSON body
Form data
Headers
Cookies
GraphQL variables
Multipart fields

Example:

{
  "project_id": "123"
}

or:

?project_id=123

or:

/api/projects/123

The important question is always:

Does the server verify that this object belongs to the current user's authorized scope?

16. Advanced Authorization Testing

Once basic testing becomes natural, start looking at relationships.

Think in terms of:

USER
 ↓
ROLE
 ↓
ORGANIZATION
 ↓
TEAM
 ↓
PROJECT
 ↓
RESOURCE
 ↓
ACTION

For each relationship ask:

Who owns it?
Who can read it?
Who can modify it?
Who can delete it?
Who can share it?
Who can transfer it?
Who can administer it?

This turns authorization testing into a structured methodology.

17. How to Test Authorization Systematically

Instead of randomly changing IDs, create a matrix.

Instead of randomly changing IDs, create a matrix.

Object           User A     User B     Admin
Project A           ✓         ?         ✓

Project B           ?         ✓         ✓

Invoice A           ✓         ?         ✓

Invoice B           ?         ✓         ✓

Admin Settings      ✗         ✗         ✓

Then verify the expected behavior.

This is much more powerful than random testing.

18. Multiple-Account Testing

Multiple test accounts are one of the most useful techniques for authorization research.

Create:

Account A
Account B

Where permitted.

Then:

A creates Object A
B creates Object B

Capture requests from A.

Then determine whether the same action against B's object is correctly denied.

The key is to preserve a clean separation:

A token → A object
B token → B object

This gives you a reliable authorization baseline.

19. Business Logic + Authorization

Some of the most interesting bugs occur when authorization interacts with business logic.

Imagine:

User
 ↓
Free Plan
 ↓
Invite Member

The frontend might hide the invitation feature.

But the backend might still accept the API request.

The problem isn't merely:

"I found a hidden endpoint."

The real question is:

Does the backend enforce the subscription restriction?

Another example:

Order
 ↓
Payment
 ↓
Refund
 ↓
Account credit

Authorization and business logic may interact in unexpected ways.

This is why advanced hunters study workflows rather than isolated endpoints.

20. Common False Positives

Not every successful request is a vulnerability.

Public objects

Some objects are intentionally public.

Shared resources

A resource may legitimately belong to multiple users.

Admin access

An administrator may legitimately access another user's data.

Predictable IDs

Predictable IDs alone are not a vulnerability.

Hidden endpoints

A hidden endpoint is not automatically vulnerable.

Different response codes

A different response does not necessarily prove unauthorized access.

Always establish:

Unauthorized access
      +
Sensitive action/data
      +
Security impact

21. Impact

Impact determines how serious the issue is.

Consider the difference between:

Can view another user's public username

and:

Can access another user's private invoices

and:

Can modify another user's account

and:

Can perform administrative actions

The vulnerability class alone doesn't determine severity.

You need to explain the actual security consequence.

22. Authorization Testing Checklist

Use this checklist during authorized testing:

[ ] Multiple accounts created
[ ] User-owned objects identified
[ ] Roles identified
[ ] Organization boundaries identified
[ ] Team boundaries identified
[ ] Object relationships mapped
[ ] GET authorization tested
[ ] Modification authorization tested
[ ] Delete authorization tested
[ ] Administrative functions checked
[ ] Nested resources checked
[ ] Cross-account boundaries checked
[ ] Cross-tenant boundaries checked
[ ] Subscription restrictions checked
[ ] Sharing/invitation workflows checked
[ ] Object lifecycle checked
[ ] Impact validated