Hunt Idor

Hunt: IDOR / Broken Object Level Authorization

Assumes hunt-core for the scope gate, two-account rule, confirmation gate, enumeration limits, stop conditions, wiki protocol, FIND output, and Deadends. Do not re-derive any of that here.

Wiki

qmd_query "IDOR BOLA insecure direct object reference access control" via wiki-search MCP

Hub: [[web-moc]] (live web index). Primary page: [[access-control]]. Payload arsenal: wiki/payloads/idor.md. Anchors: [[uuid-insecurities]] (v1-UUID timestamp/MAC when an object ID is a UUID rather than a sequential integer), [[jwt-attacks]] (chain a trusted sub/user_id claim to ATO, hand off to hunt-auth).

Attack surface signals

URL patterns: /api/v1/users/{id}, /invoices?id=, /reports/{uuid}/, /messages/{thread_id}, /admin/orgs/{org_id}/members

GraphQL: any query or mutation taking an id argument. Check for node(id: "...") global lookups - one endpoint reaching every object type, with per-type authorization frequently missing on at least one.

Rank before testing. Not all endpoints are equally likely:

• Newest features - middleware follows codebase conventions; a feature written outside them misses it.
• Bulk and export endpoints - one request, many objects, much higher severity per finding.
• Anything carrying two identifiers - see the trusted-identifier test below.
• Cross-service internal calls - the internal hop often carries no user context at all.
• File and document access - frequently a separate host or CDN with no authorization beyond knowing the ID.
• Non-GET verbs on read-looking endpoints - GET /orders/123 authorized, PATCH not.

Where the identifiers are

Check all of these; the least obvious are the least protected. Path segments, query parameters, request bodies (including nested objects), headers (X-User-Id, X-Account-Id, X-Tenant-Id), cookies, JWT claims, GraphQL variables, WebSocket messages, and file/CDN URLs.

Get B's identifiers from B. Log in as B and read them from B's own traffic, profile page, or JWT. Record in identities.md. Never obtain an identifier by incrementing until you find out whose it is - that is enumerating real users.

Decode opaque identifiers before assuming they are random. Base64 and hex frequently decode to a plain integer or a type:id pair. Where the ID is a hash, test whether it hashes something knowable (email, user ID, timestamp) and compute B's offline.

UUID: a two-part finding

A random UUID is not an authorization control, but it is a practical barrier. The finding becomes a chain:

1. The check is missing - test with B's UUID, which you legitimately hold.
2. The UUID is obtainable - find where it leaks.

Report both together. Part 1 alone gets triaged down as "requires an unguessable identifier."

Leak sources worth working: search and autocomplete endpoints, notification and activity feeds, team and member lists, verbose errors, notification emails, exported files, share and invite links, and objects you can read that reference objects you cannot.

Also verify the UUID is actually random - v1 encodes timestamp and MAC ([[uuid-insecurities]]), and hand-rolled implementations frequently emit sequential values dressed as UUIDs.

Methodology

Setup: two accounts per hunt-core. A owns, B attacks. Separate profiles.

Drive it through Burp for operator visibility. With A's request captured in Repeater or proxy history:

scripts/burp/idor-sweep.py <eng> <reqfile> --attacker-auth "Cookie: session=USER_B" --range 5

Sends owner-baseline / idor-test / bounded id sample through send_http1_request, diffs status and body, prints a verdict and a ready capture.sh burp PoC line. Honors no_bruteforce -> range 0. Do not raise --range above the hunt-core limits without operator approval.

For GUI-visible replay: create_repeater_tab for an A tab and a B tab, or send_to_intruder with a bounded number payload.

1. Log in as A, browse every feature, note every ID - object, UUID, org, invoice, thread.
2. Baseline both directions. A requests A's object. B requests B's object. Record status, length, body shape. You are testing against these, not against intuition.
3. Cross-request: B requests A's object with B's session.

# Baseline - A owns it
curl -s -H "Cookie: session=USER_A" https://target.com/api/v1/invoices/12345

# Cross-account - B attempts
curl -s -H "Cookie: session=USER_B" https://target.com/api/v1/invoices/12345

4. Rule out legitimate access before claiming anything. Is the object shared with B, in a shared team, public, or org-visible? Check the UI as B. This is the single most common false positive in this class - an app with sharing features generates them constantly.
5. Trusted-identifier test - run this on every endpoint carrying two identifiers. The highest value test in IDOR and the most frequently skipped. Make the session and the parameter disagree:

Session: account B
Body:    {"user_id": "<A's id>", "action": "..."}

• Server acts on B -> identity derived from session, parameter ignored. Correct.
• Server acts on A -> the parameter is trusted. IDOR, usually critical, fully attacker-controlled.
• Server errors on mismatch -> it compares them. Correct, and evasion is the next step.

Apply the same to JWT claims: modify sub / user_id and see whether the server derives the acting user from the claim or looks it up. Trusted claim plus weak signature chains to arbitrary account takeover - hand off to hunt-auth.

6. All verbs. GET, POST, PUT, PATCH, DELETE, HEAD, OPTIONS. Authorization applied per-method rather than per-resource is common.
7. When the direct swap 403s, it is not closed. Parameter pollution (?id=A&id=B - the check and the fetch may read different occurrences), array wrapping ({"id":["A","B"]}), nested wrapping ({"user":{"id":"B"}}), path traversal in the identifier, encoding and case variation, version downgrade (/v1/ predates the middleware /v2/ has - the most reliable of these), and batch endpoints where per-item authorization is missing.
8. Cross-tenant. Two accounts in different orgs. Categorically more severe than user-to-user inside one tenant: it breaks the isolation the product is sold on and implicates every customer. Say "cross-tenant" in the title - it changes who reads the report.
9. GraphQL. Nested traversal is the signature bug - the entry point is authorized, the resolvers are not: