IDOR Testing

Insecure Direct Object Reference: access resources belonging to other users by manipulating IDs.

• Change integer IDs: api/user/1 to api/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

1. Create Account A and Account B
2. Discover features as Account A
3. Capture requests with your ID
4. Change ID to Account B's resource
5. Send as Account A – can you read/modify Account B's data?

• 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=2 or 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.json vs /resource/1.xml

• 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

• 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

• TBHM IDOR
• Auth & Session Bugs
• Bug Chaining
• Methodology Index