Return to training

Insecure Object Reference (IDOR) - Where are they?! Shared by @zseano


IDOR's are relatively simple to find if you know where to look. An IDOR is simply http://api.example.com/api/user/139349 - in which you supply the endpoint with a userid/guid, or some sort of identification and it'll respond (usually in JSON format).

Over my time as a bugbounty 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.


So firstly, the most common places to look for IDOR are:

  • Opt out links
  • These sometimes just contain a userid arguement to opt out, and sometimes reveal the users emails. These can be found in emails they send you!

  • Mobile Apps
  • 80% of my 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.

  • Updating account settings
  • Sometimes when updating your account settings, they'll send your user_id as a parameter. Manipulating this can sometimes result in another users profile being edited.

  • Reset password
  • The same as above.

  • Google dorking/robots.txt
  • Google dorking applies to everything, as does robots.txt when looking for endpoints. Dork for optout endpoints, api systems (such as 'getuser').

Cool, i've found an IDOR.. now what?
So, every case of IDOR is different so it'll be hard to create a blueprint of "do this, do that!", so i'll go through my experience and some hurdles i've had to jump to accomplish what I want.

  • The optout links contains an encrypted ID
  • Yup, see this all the time. Sometimes they'll be a guid (c9d18ce3-e58e-4e73-91a2-f614e0312eb1), a numeric userid, or something else. Check for places this may be leaked such as when viewing another users profile, messaging them etc.

    An example case of one I found is you could invite a user to join and you'd be their referral. Upon visiting the endpoint /api/ref?user={username}, the server would respond with that users guid. So now all I had to do was grab all users usernames, hit the endpoint to retrieve guid, then visit /api/user?guid={guid_here} to reveal all their account information.

    The key bit of information I can give you here is to keep looking for ways to expose a users id/guid etc.

  • Test mobile apps!
  • A lot of people just test web apps and are missing out on TONS of juicy stuff on mobile apps. To setup burp via your phone it's extremely simple but i'll outline here incase any of my followers don't know how:

    - Run BURP and click "Proxy" -> "Options" and set interface to *, like so:



    - Grab your computers local ip (ipconfig on windows) and modify your phones wifi and modifying the HTTP proxy.



    - Server is your computers local ip, and port is 8080 (as seen above). Now visit http://burp/ on your phone and install the https cert.

    - Now your phone is setup to record mobile requests (aslong as they have no SSL pinning, lots of tuts out there for that), start using the app and look for:

    login, logout, optout, update information, view your account information (for example when wanting to update your email/password, the server may sometimes query an endpoint which returns your information), update password, etc.

    Go nuts and use every feature their app offers! :D

Common bypasses?

I can't really think of many common things to suggest when it comes to "bypassing" an IDOR "filter", since IDOR's are simply chucking anothers user_id and hoping the server responds with something related to another user. All I can suggest is also testing these endpoints for SQL injection aswell!