Accidental Observation to Critical IDOR

InfoSec Write-ups – Medium–

Insecure Direct Object Reference falls under the category for Broken Access Controls as per OWASP TOP 10 (2017 Edition). This issue usually occurs due to weak implementation of the application’s access control logics which links an identifier or an object to a particular asset say user_id parameter defines which user’s data is to be updated. IDORs are compared to server-side issues, are widely observed, and easy to identify. However, often IDORs can be tricky and an application that looks very much robust might also have IDORs.

Hi fellow hackers and bounty hunters, I hope you all are doing good. After a long, I started back to look for vulnerabilities and recently encountered an interesting IDOR vulnerability which ended up as a Critical (P1) issue. In this blog, I will be discussing the same issue.

If you enjoy reading my articles, do follow on Twitter:

I started looking for issues on an old target’s subsidiary, let’s say
I logged into the account after 3–4 months so, upon successful login, it asked me to change the password as it’s their policy to rotate password every few months. On the password change page, the URL looked something like this:

Looking at the ?id= parameter, I tried to change values but no success. Later on, after changing the password with the normal flow, I logged in to the application and navigated back to the change password page.

Now, this time the URL looked something like this:

This time the ?id= parameter was not present. Now, it was a little strange for the application with the same endpoint to use two different flows. Next, I moved to my account page and the URL looked something like this:

Further, I modified the URL by adding ?id= parameter with a value 88 and the new URL looked like this:

Now, I was able to access the details of the user with id=88. At this point, I was able to change the email of the user. Further, I created another account and change it’s Email to attacker email. Now I can call a password reset link on the attacker-controlled email and without user interaction, I was able to perform a full account takeover.


  1. Always check all possible flows for every endpoint. Sometimes you may find an interesting flow that can be utilized elsewhere in the application.
  2. Whenever you see /myaccount or similar endpoints with no reference to the user’s unique identifier, try to fuzz with the common identifier parameters like uid, id, user_id, oid, etc.

If you enjoyed reading the article do clap and follow on Medium and Twitter:






Accidental Observation to Critical IDOR was originally published in InfoSec Write-ups on Medium, where people are continuing the conversation by highlighting and responding to this story.

View original article on InfoSec Write-ups – Medium

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s