zseano:idor
Table of Contents
IDOR Testing
Insecure Direct Object Reference: access resources belonging to other users by manipulating IDs.
Core Technique
- Change integer IDs:
api/user/1toapi/user/2 - Try integers even when you see GUIDs or hashed IDs – server may accept both
- Check for GUID leaks: public profiles, image URLs, page source
- Inject
“id”:“1”into JSON POST bodies even when not normally present - Hunt on mobile apps first – they use APIs directly and often have weaker controls
- Look specifically for PUT requests – they often modify data by ID
Two-Account Testing
- Create Account A and Account B
- Discover features as Account A
- Capture requests with your ID
- Change ID to Account B's resource
- Send as Account A – can you read/modify Account B's data?
Bypassing IDOR Protection
- Encoded/hashed IDs – try predicting or finding leaks of the underlying integer
- Leaked IDs – check other API responses, public profile URLs, image filenames
- Offer an ID even when not asked – add
?id=2or inject into JSON body - Blind IDORs – no visible response but action still occurs (email sent, data deleted)
- Change the request method – GET may be restricted but POST/PUT not
- Change the file type –
/resource/1.jsonvs/resource/1.xml
High-Value IDOR Targets
- Password changes, account recovery flows
- Non-public images, receipts, private documents
- Shipping details, purchase orders
- Messaging/DM systems
- User creation and deletion
- Payment processing views
- Admin actions
Escalation
- Horizontal: access other users' data at the same privilege level
- Vertical: access admin functions as a regular user
- Chain with recon: enumerate all user IDs to mass-exfiltrate data
See Also
zseano/idor.txt · Last modified: by drew
