Bug Bounty Hunter — Let’s Understand and Recognize IDOR Vulnerability / Part 1

9 min readJul 11, 2023

IDOR (Insecure Direct Object Reference) is a software developer’s nightmare and a bug bounter favorite. It often emerges from unexpected spots. Things like changing a letter and adding an extra parameter can suddenly get you into an IDOR. Let’s get to know and understand the IDOR vulnerability part by part. The first thing to remember is that the way to discover a vulnerability is to have a good understanding of the reasons for its occurrence.

Chapter 1: What is IDOR?

IDOR (Insecure Direct Object Reference), which is one of the security vulnerabilities frequently encountered in web applications with a database as a base, is a problem that occurs when correct authorization and verification checks are not made. This vulnerability allows an attacker to directly access sensitive data or resources.

IDOR relies on references to objects that define user-accessible resources in a web application. These resources can be sensitive data such as user information, payment transactions, and orders, which are usually kept in the database. An attacker with an IDOR vulnerability in the web application could gain access to these data or resources that an unauthorized user would not normally have access to.

Chapter 2: How should we look for an IDOR vulnerability?

Understanding the Functions of the Web Application: The first step is to understand the functions of the target web application. It is important to determine which resources can be accessed, how authentication and authorization are performed, and which objects are associated with reference numbers or identities.
Examining Authorization and Authentication Controls: There are often vulnerabilities in authorization and authentication controls for IDOR attacks. Examine the application’s authorization process and test the security of authorization controls. For example, make sure that session authentication is enabled and that the user has sufficient privileges.
Inspect URL and Parameters: One symptom of IDOR vulnerabilities is the use of parameters that define user-specific data or resources in URLs or form entries. Examine these parameters and try to identify vulnerabilities that could allow users to manipulate credentials or objects.
Monitoring Sessions and Authentication: Sessions and authentication processes are often associated with IDOR vulnerabilities. Follow the relevant session authentication steps and try to understand how the session is managed, how users carry their session ID, and how the session grants access to resources.
Examine Data and Resources: Examine data and resources in the app. Try to identify sensitive data or resources that the user should not normally have access to. For example, the accessibility of sensitive data such as orders, user profiles, and payment transactions should be checked.
Testing Reference Manipulation: IDOR attacks are performed by manipulation of reference numbers or objects. Test whether direct access to targeted resources can be achieved by changing or manipulating reference numbers or objects. This may include changes to URLs or form entries.
Creating Test Cases: Create test cases to detect IDOR vulnerabilities. Run tests with different user roles (eg regular user, administrator) and test access to resources. Check if an unauthorized user can access sensitive data or resources.

Chapter 3: Can I scan for IDOR vulnerabilities?

This subject is a bit strange actually, if you are not very new to this subject, you may have heard that there are tools that can detect many security vulnerabilities such as XSS, SQL, XXE, CSTI and CSRF. But for IDOR this is not usually the case. Although it is a fact that some security tools such as Nessus, Acunetix and Snyk can find IDOR, they often fail to detect all IDOR vulnerabilities. The reason is that the IDOR vulnerability depends on the design and authorization methods of web applications. While common security scanners and testing tools offer configurable and customizable features to detect IDOR vulnerabilities, it is not currently possible to fully automate this.

Chapter 4: What are the methods applied?

I will prefer to describe these stages one by one by scripting, the main reason for this is that it is difficult to discover IDOR without fully understanding where and what you can change.

Scenario 1: If you have the ability to create an account, send requests for each user such as:

Creating Accounts or Enumerating Users:

# First User

POST /accounts HTTP/1.1
Host: example.com
Content-Type: application/json

{
  "username": "user1",
  "password": "pass1"
}

# Second User

POST /accounts HTTP/1.1
Host: example.com
Content-Type: application/json

{
  "username": "user2",
  "password": "pass2"
}

Controlling Access by Changing the Parameter Value: Suppose you have a login authorized to the account of the first user. Submit a request as the second user, using the value of the “id” parameter that the first user used to access their account, as follows:

# Here you made a request to go to the second user's profile, 
# but you changed the id parameter to the first user's parameter

GET /account?id=user1 HTTP/1.1
Host: example.com

Scenario 2: Let’s say there is a page in a web application that can view users’ profiles. Each user’s profile picture is associated with a unique object reference on the server. Normally, a user should only have access to their profile picture. However, if the web application has an IDOR vulnerability, attackers can manipulate another object reference (for example, the user’s ID number or other parameters) to display another user’s profile picture.

The attacker can guess the object reference of the target profile or try to obtain the object reference of the target profile by experimentally modifying it. In this way, an attacker can gain unauthorized access to another user’s profile picture. This qualifies as an IDOR if the user’s image is in a private state and still accessible.

For example, profilepictureisveryimportant.com/profiles/user1/<md5_user1> can get a profile picture of the user named ‘user1’.

In this case, the attacker sends a request like profilepictureisveryimportant.com/profiles/user2/<md5_user2> to display the profile picture without permission.

Scenario 3: An IDOR vulnerability occurs when authorization and authentication controls are inadequately or incorrectly implemented. In a web application where the user has the authority to delete their own account, it may be possible for a user to delete another user’s account without permission with the IDOR vulnerability.

# User A sends a request to delete his account as follows:

DELETE /accounts/userA HTTP/1.1
 Host: example.com

This request is performed in accordance with an authentication mechanism where the user has the authority to delete their own account. However, if there is an IDOR vulnerability, User B can send a request to delete another user’s account instead of deleting his own account, as follows:

DELETE /accounts/userA HTTP/1.1
 Host: example.com

In this case, User B can delete User A’s account without permission, as there are no correct authorization and authentication checks.

Scenario 4: Allows users to bypass authorization and authentication checks to gain access to sensitive information of other users.

In a web application, users can view the profile information of other users. Profile information includes sensitive information (such as date of birth, address and phone number). The web application does not properly implement authorization and authentication controls and performs poor user authorization controls on accessing profile information.

Sample requests:

GET /profile?id=userA HTTP/1.1
Host: example.com

# However, if there is an IDOR vulnerability, User A can manipulate the "id" 
# parameter to display another user's profile information, such as:

GET /profile?id=userB HTTP/1.1
Host: example.com

Scenario 5: Users can generate, delete or view their own API keys in certain situations:

# user "user1" sends a request to view his API key as follows:

GET /api-keys/user1 HTTP/1.1
Host: example.com

# Then user1 wants to see user2s api key instead of himself.

GET /api-keys/user2 HTTP/1.1
Host: example.com

# "user1" sends a request to delete its API key as follows:

DELETE /api-keys/user1 HTTP/1.1
Host: example.com

# Then user1 wants to delete user2s api key instead of himself.

DELETE /api-keys/user2 HTTP/1.1
Host: example.com

# "user1" sends a request like the following to generate an API key on behalf of another user, "user2"

POST /api-keys/user2 HTTP/1.1
Host: example.com

Scenario 6: Sometimes the comments can be private. However, if there is an IDOR vulnerability, a user can view another user’s comments without permission.

# User A sends a request like below to view his own comment

GET /comments/123 HTTP/1.1
Host: example.com

# If IDOR is available, it can also display another user's comment.

GET /comments/456 HTTP/1.1
Host: example.com

Scenario 7: In an e-commerce web application, the prices of products are often associated with a specific ID or reference number. Normally, a user can only change or update the prices of their products. The web application must properly implement authorization controls and ensure that users can only access its own products. However, if there is an IDOR vulnerability, a user can change the price of another user’s product without permission.

# User A sends a request like below to change the price of his product

PUT /products/123/price HTTP/1.1
Host: example.com
Content-Type: application/json

{
  "...": ...
  "price": 50
  "...": ...
}

# However, if there is an IDOR vulnerability, User B can send a request as follows to change the price of another user's product without permission.

PUT /products/456/price HTTP/1.1
Host: example.com
Content-Type: application/json

{
  "...": ...
  "price": 100
  "...": ...
}

Scenario 8: Hiding or hiding identities using the encoding method (md5, base64, etc.) can lead to security risks when combined with IDOR vulnerability. When authentication controls are inadequate or incorrectly implemented, coded identities may be allowed to be used directly without deciphering the correct identities. This may result in unauthorized access and privacy violations.


# aGFja2VyQGhhY2tlci5jb20 = hacker@hacker.com
# aGVkZWZAaGVkZWZlbWFpbC5jb20 = target@targetemail.com

# Normally, the hacker uses this type of request to view his profile.

GET /GetUser/aGFja2VyQGhhY2tlci5jb20 HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/88.0.4324.150 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9

# The hacker sends the target person's email address by encoding it with base64

GET /GetUser/aGVkZWZAaGVkZWZlbWFpbC5jb20 HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/88.0.4324.150 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9

Scenario 9: A web application may have an endpoint associated with a specific ID number to delete users’ accounts. Usually, users can use this endpoint to delete their own account. The web application should only allow users to delete their own account. However, if IDOR is vulnerable, requests using HTTP methods (GET, POST, PUT, DELETE, etc.) have the potential to bypass authorization checks.

# User A sends a request like below to delete his own account

POST /users/delete/hacker_id HTTP/1.1
Host: example.com
Content-Type: application/json
Authorization: Bearer <access_token>

Since POST is used as the HTTP method in this request, the user can have the authority to delete their own account.
The “Authorization” header is used for authorization and the user’s access token is provided.
The web application validates this request with authorization checks and successfully deletes the user’s own account.

# User B can send a request like below to delete another user's account

GET /users/delete/target_id HTTP/1.1
Host: example.com
Authorization: Bearer <access_token>

Because GET is used as the HTTP method, the web application usually rejects the account deletion and returns HTTP status code 403 Forbidden.

However, if there is an IDOR vulnerability, the application can bypass the authorization checks and successfully process the request without checking for this condition.

In this case, when authorization checks are insufficient, a user may have the ability to delete another user’s account without permission.

Scenario 10: If a web application is accessing data via a particular parameter, it is important that this parameter be subject to security checks. Normally, parameter names are specified correctly, allowing users to access only their own data. However, if IDOR is vulnerable, parameter names can be changed to bypass authorization checks.

# User A sends a request to get his album's data as follows

GET /api/albums?album_id=<album id> HTTP/1.1
Host: example.com
Authorization: Bearer <access_token>

# User B can send a request like below to get data of another users album without permission

GET /api/albums?account_id=<account id> HTTP/1.1
Host: example.com
Authorization: Bearer <access_token>

Conclusion

When developing web applications, it is important to take precautions against IDOR vulnerabilities to minimize security vulnerabilities and protect the confidentiality of user data. Careful planning of authorization controls, proper implementation of authentication mechanisms, and effective configuration of data access restrictions help make web applications more secure.

Remember, building a secure web application requires ensuring not only functionality but also security, and again, it’s important to know how to develop those applications to discover where security is lacking. I explained 10 possible IDOR situations. To be notified of my next article, you can subscribe to my e-mail newsletter or follow me on Medium. Take care of yourselves.

Best Regards