hunt-idor

---

name: hunt-idor description: Hunting skill for idor vulnerabilities. Built from 26 public bug bounty reports. Use when hunting idor on any target. sources: github, hackerone_public report_count: 39

Crown Jewel Targets

Why IDOR pays big:

• Direct access to other users' data without authentication bypass — clear, demonstrable impact
• Chains easily with privilege escalation, financial fraud, and account takeover
• Affects virtually every application with user-owned resources

Highest-value asset types (by payout potential):

| Asset Type | Why It Pays | |---|---| | Financial documents / billing APIs | PII + financial data exposure (Shopify, Uber, PayPal) | | Private repositories / source code | IP theft, critical data loss (GitHub) | | User messages / DMs | Privacy violation at scale (Reddit) | | Account management endpoints | User addition, deletion, privilege escalation (PayPal, Mozilla) | | Business/org administration | Cross-tenant escalation, employee PII (Uber) | | Content moderation/admin actions | Operational sabotage (Reddit mod logs) |

Programs that pay most for IDOR:

• Platforms with multi-tenancy (SaaS, B2B tools)
• Fintech and payment processors
• Social platforms with private content
• Developer tools with org/repo isolation

---

Attack Surface Signals

URL patterns that scream IDOR:

/api/v1/users/{id}/
/api/v*/orders/{order_id}
/invoices/download?id=
/reports/{uuid}/
/messages/{thread_id}
/admin/orgs/{org_id}/members
/migration/{migration_id}/files
/graphql (query params with IDs)
/api/business/{business_id}/
/vouchers/{voucher_id}/policy

Response header signals:

• Content-Type: application/json on endpoints accepting raw IDs
• No X-Frame-Options or CORS misconfigs paired with ID params
• Authorization: Bearer tokens that are user-scoped but hit org-level resources

JavaScript source patterns:

// Look for hardcoded or interpolated IDs in JS
fetch(`/api/v1/users/${userId}/profile`)
axios.get('/invoices/' + invoiceId)
graphql query { billingDocument(id: $docId) }
// Redux/state stores exposing foreign IDs
state.currentUser.organizationId

Tech stack signals:

• GraphQL endpoints (query-based IDORs are often missed)
• REST APIs with sequential integer IDs (most vulnerable)
• UUIDs that are predictable or leaked in other responses
• Multi-tenant SaaS apps with org_id, account_id, business_id params
• Mobile apps (Burp the APK — mobile APIs often skip authorization checks)

---

Step-by-Step Hunting Methodology

1. Map all object references in the application

   • Browse every feature authenticated as User A
   • Capture all requests in Burp Suite
   • Filter for requests containing: id=, _id=, uuid=, /v1/{noun}/{id}, query params with numeric/UUID values

2. Enumerate ID types

   • Sequential integers → enumerate ±1, ±100
   • UUIDs → check if they appear in other responses or JS files
   • Hashed IDs → check if leaked in public endpoints, metadata, or GraphQL introspection

3. Create two separate accounts (same privilege level)

   • User A: resource owner
   • User B: attacker account
   • Log all IDs belonging to User A while authenticated as User A

4. Replay User A's resource IDs as User B

   • Replace session cookie/token with User B's credentials
   • Send identical requests referencing User A's object IDs
   • Test ALL HTTP verbs: GET, POST, PUT, PATCH, DELETE on each endpoint

5. Test cross-tenant/cross-org scenarios

   • Create accounts in separate organizations/businesses
   • Test if Org B's session can reference Org A's IDs
   • Pay special attention to admin/management endpoints

6. Test GraphQL specifically

   • Run introspection: { __schema { queryType { fields { name } } } }
   • For every query/mutation taking an id argument, substitute another user's ID
   • Test both queries (read) and mutations (write/delete)

7. Test write/destructive operations, not just reads

   • Can User B DELETE User A's resources?
   • Can User B MODIFY User A's content?
   • Can User B ADD themselves to User A's account?

8. Chain IDORs together

   • Use one IDOR's leaked data (org IDs, user IDs) to fuel the next
   • IDOR → leaked ID → second IDOR → privilege escalation

9. Test state-changing edge cases

   • Expired tokens/invites that can still be accepted
   • Race conditions on resource IDs
   • Indirect references: ?sort=id or ?filter[user_id]=

10. Document the exact differential

    • Confirm User B has NO legitimate access to User A's resource
    • Screenshot/log the 200 OK vs expected 403/404

---

Payload & Detection Patterns

Basic IDOR test with curl (swap cookie/token):

# Get User A's resource ID while authenticated as A
curl -s -H "Cookie: session=USER_A_SESSION" \
  https://target.com/api/v1/invoices/12345

# Replay with User B's session
curl -s -H "Cookie: session=USER_B_SESSION" \
  https://target.com/api/v1/invoices/12345

# Success = 200 OK with User A's data

GraphQL IDOR test:

curl -s -X POST https://target.com/graphql \
  -H "Authorization: Bearer USER_B_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"query":"{ billingDocument(id: \"USER_A_DOC_ID\") { id amount pdfUrl } }"}'

Enumerate sequential IDs with ffuf:

ffuf -u "https://target.com/api/v1/orders/FUZZ" \
  -w ids.txt \
  -H "Authorization: Bearer USER_B_TOKEN" \
  -mc 200 \
  -o idor_results.json

Generate sequential ID wordlist:

# Generate IDs around a known value
known_id = 48291
with open("ids.txt", "w") as f:
    for i in range(known_id - 500, known_id + 500):
        f.write(str(i) + "\n")

Burp Intruder payload for IDOR scanning:

GET /api/messages/§12345§ HTTP/1.1
Host: target.com
Authorization: Bearer USER_B_TOKEN

# Mark §12345§ as injection point
# Use numeric sequential payload: 12000-13000
# Filter responses by length difference or status 200

JavaScript scraping for leaked IDs:

# Find IDs in JS bundles
curl -s https://target.com/static/app.js | grep -Eo '"id":"[a-f0-9-]{36}"' | sort -u

# Find object references in API responses
curl -s -H "Cookie: session=USER_A" \
  https://target.com/api/v1/dashboard | python3 -m json.tool | grep -i "_id"

Grep patterns for source code review:

# Missing authorization checks in common frameworks
grep -r "findById\|findOne\|getById" --include="*.js" .
grep -r "params\[:id\]\|params\['id'\]" --include="*.rb" .
grep -r "request\.args\.get\('id'\)" --include="*.py" .

# Look for direct ORM queries without user scoping
grep -r "Model\.find(params" --include="*.js" .
# vs secure pattern: Model.find({ id: params.id, userId: req.user.id })

IDOR via HTTP method tampering:

# Try undocumented methods
for method in GET POST PUT PATCH DELETE OPTIONS HEAD; do
  echo "=== $method ==="
  curl -s -X $method \
    -H "Authorization: Bearer USER_B_TOKEN" \
    https://target.com/api/v1/users/USER_A_ID/profile
done

---

Common Root Causes

1. Missing ownership check in ORM queries

   // VULNERABLE: fetches any record
   const invoice = await Invoice.findById(req.params.id);
   
   // SECURE: scopes to authenticated user
   const invoice = await Invoice.findOne({ _id: req.params.id, userId: req.user.id });
   

2. Authorization at the route level, not object level

   • Developer checks "is user logged in?" but not "does this user own this object?"
   • Middleware confirms authentication; individual handlers skip ownership validation

3. Trusting client-supplied IDs in request bodies

   • Mobile apps or SPAs send org_id in POST body; server uses it directly without verifying caller belongs to that org

4. GraphQL resolvers without field-level authorization

   • Query resolvers fetch by ID from database without checking if the requesting user has permission
   • Especially common when resolvers are auto-generated from schema

5. Inconsistent authorization across HTTP verbs

   • GET endpoint is protected; POST/DELETE on same resource path is not
   • Common in APIs built incrementally by different developers

6. Indirect references exposed via related objects

   • Object A (accessible) contains a reference to Object B (should be private)
   • Developer only protects direct access to B, not indirect references through A

7. Race conditions and state-based IDORs

   • Authorization checked at creation time, not at access time
   • Invites/tokens remain valid after the granting permission is revoked

8. Multi-tenant isolation failures

   • Developers implement per-user access control but forget cross-org boundaries
   • user_id check present; org_id / tenant_id check absent

---

Bypass Techniques

Defense: UUIDs instead of sequential integers

• Bypass: UUIDs often leak in other API responses, notification emails, webhooks, GraphQL queries, or JS source
• Technique: Harvest UUIDs from accessible endpoints, then replay against restricted ones

Defense: Indirect/hashed object references

• Bypass: Decode the hash (often base64 or simple obfuscation), or find the original ID in another response
• Technique: echo "dXNlcl8xMjM0NQ==" | base64 -d → user_12345

Defense: Short-lived tokens per resource

• Bypass: Tokens sometimes reusable across users if server only validates token format, not binding
• Technique: Use your own token to access another user's resource ID

Defense: Rate limiting on enumeration

• Bypass: Slow enumeration (1 req/5s), use distributed IPs, or exploit non-enumeration IDORs (you already know the target's ID from another leak)

Defense: Checking user_id in WHERE clause

• Bypass: Check if the same endpoint exists at a different API version (/v1/ vs /v2/) — authorization logic is often version-specific
• Technique: Check JS bundles for older API version calls

Defense: CORS restrictions

• Bypass: IDOR doesn't require cross-origin exploitation — you're testing API endpoints directly with your own session

Defense: "Opaque" references via server-side sessions

• Bypass: Look for any endpoint that returns the internal ID, then use it elsewhere; APIs often expose IDs in Location headers, error messages, or metadata

Defense: Parameter filtering/WAF on common patterns

• Bypass: Try nested JSON {"data": {"id": "VICTIM_ID"}}, HTTP parameter pollution ?id=own_id&id=victim_id, or parameter name variations user_id, userId, uid, account

---

Gate 0 Validation

Before writing the report, answer all three:

1. What can the attacker DO right now? Be specific: "Attacker with a valid account can send a GET request to /api/v1/invoices/{victim_invoice_id} and receive the victim's full billing document including name, address, and payment amount — without any relationship to that account."

2. What does the victim LOSE? Map to CIA triad: confidentiality (data exposed), integrity (data modified), or availability (data deleted). "Victim loses confidentiality of private financial records" or "Victim's content is deleted by a third party" — vague answers fail.

3. Can it be reproduced in 10 minutes from scratch?

   • Two fresh accounts created ✓
   • Exact HTTP request documented with victim's ID ✓
   • 200 OK response showing victim's data (or confirmed state change) ✓
   • No reliance on pre-existing state or timing ✓

   If you can't demo it reproducibly, do not file the report.

---

Real Impact Examples

Scenario 1: Financial Data Exposure + Cross-Account Billing Fraud (Uber-style) An attacker discovers two related IDORs: one allows reading any organization's voucher policy configuration (exposing org IDs, employee email lists, and payment methods), and a second allows modifying voucher policies using those leaked IDs. Chained together, this enables the attacker to redirect charges to an arbitrary business account, expose employee PII across or