hunt-idor

⚠️ AUTHORIZED USE ONLY This skill is for educational purposes or authorized security assessments only. You must have explicit, written permission from the system owner before using this tool. Misuse of this tool is illegal and strictly prohibited.

Mandatory confirmation gate Before running any command that probes, exploits, changes, persists on, extracts data from, or attempts credential access against a target:

1. Ask the user to state the exact target URL, IP, account, or resource.
2. Ask the user to confirm written authorization and the permitted scope.
3. Show the exact command(s) and explain their expected effect.
4. Wait for explicit confirmation in the current conversation.

Without that confirmation, remain read-only and provide defensive guidance only. Prefer a sandbox, disposable VM, or controlled lab.

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

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 } } } }

…