# Web Idor

> Insecure Direct Object Reference / broken access control on web objects. Load when a request references an object by id you can change: /account/1234, ?invoice=987, UUIDs in URLs/bodies, "download", "view", "edit" endpoints, numeric or guessable identifiers, or multi-tenant apps. Signals: sequential IDs, object refs in JSON, role/owner not re-checked.

- Skill: `noorqureshi/web-idor` (Agent Skill)
- Install (CLI): `npx skillmds@latest add noorqureshi/web-idor`
- Raw SKILL.md: https://api.skillmd.com/api/skills/noorqureshi/web-idor/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Finance & Business
- Author: NoorQureshi (https://skillmd.com/u/noorqureshi)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/noorqureshi/web-idor

---


# Insecure Direct Object Reference (IDOR)

## When it applies
The app trusts a client-supplied identifier to decide which object to return or mutate, and
authorization is checked at the *route* ("is logged in?") but not at the *object* ("does THIS
user own THIS object?").

## Why it works
Access control is missing at the data layer. The server maps id → row and returns it without
asking whether the current session is allowed that row. Sequential/predictable ids make
enumeration trivial; even UUIDs leak (in listings, referrers, other endpoints).

## Method
1. **Get two accounts** (A = attacker, B = victim). Do an action as B, capture the request,
   note the object id.
2. **Replay as A**: swap in B's id (or A's session + B's id). Returned/changed = IDOR.
3. **Cover all verbs & spots**: id in path, query, body, JSON, cookie, and `X-*` headers;
   test GET/POST/PUT/DELETE — read-only checks often miss write IDOR.
4. **Automate the two-session diff** with Burp **Autorize**/**AutoRepeater**: it re-sends every
   request with A's cookies and flags responses that shouldn't succeed.
5. **Enumerate** where ids are sequential to size impact (count of exposed records), without
   hoarding real PII.

## Gotchas
- "UUID so it's safe" is false — UUIDs appear in other responses, emails, and referers.
- Sometimes the id is hashed/encoded (base64, `md5(id)`) — decode, tamper, re-encode.
- Mass-assignment overlaps: changing an `owner_id`/`user_id` in the body can grant access.
- Blind write-IDOR: no response body, but the victim object changed — verify from B's view.

## Verify success
You read or modify an object belonging to another tenant/user using your own session.
Screenshot both: your session token + the victim's data/changed state.

## References
PortSwigger access-control labs; OWASP API Security Top 10 (BOLA).