Tip from @zseano
Even if you see some type of GUID/encoded value being used, don't think "too hard to test for IDOR". Generate GUIDs, look for leaks (for example When a user uploads a profile photo and it's saved, they use the guid as an identifier sometimes!), or look for patterns in the encoding.
Learning about Insecure Direct Object Reference (IDOR)
What is an Insecure Direct Object Reference? Imagine the URL
https://api.example.com/api/user/139349 - in which you supply the endpoint with a userid/guid, or some sort of identification and it'll execute & respond. In this case, it's looking for userid
139349. An application that is not vulnerable will not let you change
139349 to another users ID, but if it is vulnerable, the IDOR bug would enable a malicious user to enumerate
https://api.example.com/api/user/x & leak users information. So the tldr, being able to modify/view other users' info from simply changing one value (typically integer value)
Over my time as a bug bounty hunter i've reported countless idors resulting in ~250,000,000 details being leaked, and this post is designed to outline the process I use. IDORs can exist throughout the entire application so it is always suggested that if you see IDs then to always test, even if they are guids or some type of "encrypted id". Look for potential leaks of this ID (public profile?) or look for patterns and see if you can generate your own & run it through burp intruder.
See some type of unique identifier (ID) in a request? Test it.
IDOR bugs exist in more places than you think, especially on mobile apps! Mobile apps will typically query an API with a users ID and this ID can be manipulated to view any other users' information. Sounds simple right? That's because honestly, it really is that simple. An API is designed to take user input (the users ID,
https://api.example.com/user/123456), process & return information. One IDOR on an API will more than likely lead to lots more.
Opt out links
These sometimes just contain a userid arguement to opt out and will usually reveal the users emails. These can be found in emails they send you. Signup to all newsletters!
80% of my IDOR findings are from mobile apps. Most mobile apps use a simple API system to log the user in, display their information etc. A lot of API's just take a userid parameter and will usually reveal all their information to you, as shown above in the example. If you see some type of GUID then why not try a GUID generator, generate 10,000 & see what happens. Or if they look like they are encrypting/encoding it somehow then look for patterns. I once had a case where a certain set of a-z characters were used and I was able to mass-generate valid IDs from a simple script.
Updating account settings
Sometimes when updating your account settings, they'll send your userid as a parameter. Manipulating this can sometimes result in another users profile being edited. Don't forget that if one feature is vulnerable to IDOR then it may be a site-wide issue (and don't forget to check mobile site!). Even if you do not see your ID in the post data, just simply try adding it.
userid=, especially if it is a GraphQL query or JSON post data (if it's
The same as above. Mongobug was able to do this on Uber but instead of a userID, he had to supply the users number. Not hard to obtain though right and earned himself a nice $10k, check it out here: https://hackerone.com/reports/143717
Anytime you see some sort of indentifer
This can mean a simple ID (
1), or a guid (
425d1126-4139-4067-ac68-d9caafdf2b46), or some other value. The key is to look for values which identifies you when interacting with the site/API, then to check if you can provide another users ID (your second testing account), and if yes, you have a bug. If it's something like a GUID then you should look for potential places it may be leaked on the site.
However with that said, don't just look for integer values. Perhaps to update your profile your username is used to validate who's to update, so simply trying another username you control will let you test for IDOR. To learn more about some common payloads i've used (and areas I found them in) you can check the useful payloads tab on the left.
We actually had an interesting IDOR bug on our Hackevent Firstblood which was replicated from a real finding. You can view disclosed issues on our hackevent page.