idor-analysis

IDOR Hunting Playbook

IDOR is the #1 source of bug bounty payouts because it's simple, ubiquitous, and scanners can't find it (authorization is business logic). Every endpoint that takes an object ID is a candidate.

1. Sources

• URL path segments: /api/users/123/invoices/456
• Query string: ?user_id=123
• JSON body fields: {"orderId": 123}
• Headers used as auth scope: X-Tenant-ID, X-Customer-Id
• JWT claims that downstream handlers trust: sub, tenant, role
• WebSocket subscription filters
• GraphQL arguments (user(id: 123))

2. Audit workflow

Step 1 — enumerate object-handling endpoints

# REST
grep -rE '@(Get|Post|Put|Delete|Patch)Mapping.*\{[a-zA-Z]+Id\}' /workspace/src   # Spring
grep -rE 'router\.(get|post|put|delete)\([^)]*:id' /workspace/src                # Express
grep -rE '@app\.route\([^)]*<[a-z]+:' /workspace/src                             # Flask
grep -rE 'resources?\s+:[a-z]+' /workspace/src                                   # Rails

# GraphQL
grep -rE 'type Query|type Mutation' /workspace/src
grep -rE '\w+\(id: ID' /workspace/src

Step 2 — for each endpoint, answer three questions

1. Does it check who the caller is? (auth middleware / decorator)
2. Does it check whether the object belongs to the caller? (ownership check / tenant filter in the query)
3. Does it check whether the caller's role permits the action? (RBAC / policy engine)

A "no" to question 2 = horizontal IDOR (read/write other users' data). A "no" to question 3 = vertical IDOR (regular user → admin action).

Step 3 — ownership-check grep patterns

# Django: should have .filter(user=request.user) on the queryset
grep -rE 'Model\.objects\.get\(pk=' /workspace/src | grep -v 'user=request\.user'

# Rails: should have current_user.posts.find(params[:id])
grep -rE 'Post\.find\(params\[:id\]\)' /workspace/src

# Spring: should have @PreAuthorize("#id == principal.id")
grep -rE 'findById\(id\)' /workspace/src | xargs -I{} grep -L '@PreAuthorize\|@PostAuthorize'