Insecure Direct Object Reference (IDOR)
Methodology
Identifying Object References
Look for URLs, forms, or APIs that reference internal objects directly. Common patterns:
/my-account?id=wiener
/blogs?userId=773fea0b-d694-496b-974b-4ae2b8d8cc9c
/user?id=123
/profile?id=wiener
/account/456
/message?id=90210
/email?id=105
/ticket/view?ticketId=320
/download?file=invoice-002.pdf
/file?id=resume123.docx
/document/8756
/order?id=31415
/checkout?orderId=1234
/invoice?id=980
/admin/upgrade-user?id=2
/update-role?userId=773
/post?postId=89
/comment/delete?commentId=2048
/logs?user=admin
/audit?id=777When References Are Encoded
If object references are hashed or encoded (e.g., base64, md5, URL encoding), understand the encoding method and reverse it.
Common encoded parameters:
uidusernamefilecontract
Example:
Base64-decode: MQ== → 1
Mass Enumeration Example
Download Exploitation Script
Exploiting Insecure APIs
Step 1: User Enumeration
Sample output:
Step 2: Escalation via Insecure Function Calls (PUT)
This allows privilege escalation by overwriting the role field.
Combining Leaks + Writes = Complete Takeover
First, enumerate user data (UUIDs, roles, etc.).
Then, modify those values via IDOR-vulnerable PUT endpoints.
You can:
Change all users’ emails to one you control.
Inject XSS in
aboutfields.Change user roles in bulk.
Last updated