IDOR labs

A practical playbook — from recon to proof of concept.

1. 1

   Map objects with an identifier

   Create an account, browse and note every endpoint that takes an id, uuid, filename or slug of your own. Those are the candidates.

   GET /api/orders/1337   ·   GET /invoices/INV-1337.pdf   ·   GET /users/42/settings

2. 2

   Enumerate other people's IDs

   Decrement/increment the identifier with your session. If it returns another user's data, it's IDOR. Automate with Burp Intruder.

   GET /api/orders/1336   →   another customer's data = IDOR

3. 3

   Attack 'opaque' identifiers

   UUID v1 carry timestamp+MAC and are predictable; base64 IDs usually decode to integers. Don't assume they're safe.

   echo 'dXNlcjoxMzM3' | base64 -d   →   user:1337

4. 4

   Fuzz tenant headers and parameters

   Many apps trust X-Account-Id, X-User-Id or ?org= without re-validating. Swap them for the victim's.

   X-Account-Id: 1338   (keeping your own session cookie)

5. 5

   Test mass assignment

   Add privileged fields to your own update body. If the backend accepts them, you escalate from IDOR to takeover.

   PUT /api/users/me   {"email":"me@x.com","role":"admin"}

6. 6

   Document with two accounts

   For clean triage, prove it with account A reaching a resource created by account B. Reproducible in 30s.

   Account A (id 100) reads GET /api/orders of account B (id 200)