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

| 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