Insecure Direct Object Reference (IDOR)

  • Home
  • Blog
  • Insecure Direct Object Reference (IDOR)
Insecure Direct Object Reference (

Insecure Direct Object Reference (IDOR) was listed in the OWASP (Open Web Application Security Project) Top 10 back in 2007 and currently falls under the A5 Broken Access Control category. Idor has been part of the Top 10 vulnerabilities throughout the decade. In Insecure direct object reference an unauthorized request is being made to access or modify objects beyond the end user’s scope. 

Let us get started with some basics, 

Idor Introduction 

Insecure Direct Object References (IDOR) occur when an application grants direct access to objects based on the user’s input. Because of this vulnerability, attackers can bypass authorization and access resources in the system directly, such as database records or files. By modifying a parameter used to directly point to an object using an insecure Direct Object Reference, an attacker can bypass authorization and gain access to resources directly. Using the Human eye to detect and observe from where the request is being made and how it functions in the web application certainly makes it more likely to find these vulnerabilities. 

How Idor Works? 

In most cases web applications expose the user_ids or user_keys in the request or response, this enables the attacker to access or modify the data present for a specific end user. 

Idor Working (

To understand this thoroughly, 

is the request made by the web application to update profile of end user 99. The update in URL specifies the function and parameter “id” is responsible for detecting valid and authenticated user account. What if we change this request from 


This exposes the unauthorized data to the attacker and carries out unethical actions if the parameter “id” is used with direct object references. Here web server and application are completely dependent upon the user input which is used directly to refer to the objects head on. This was simple demonstartion to understand IDOR better.

Let us see how to detect IDORs in the wild!! 

Detecting IDORs (Insecure Direct Object References)  

 IDORs are hard to prevent since automatic vulnerability scanners fail to detect them. To spot an insecure object reference, you need to have a general understanding of the functioning of an application or website, requests and responses or the information that should be revealed by them in case of Api as well as web applications. Here are some methods to detect Idor.

Idor Detection (
  1. Exposed internal identifiers such as UID, ID within the application 

Exposer of identifiers which uniquely represents a set of data in the application results in unauthorized actions from unethical sources. The ids which directly represent the access structure by which an attacker is able to detect the possibility of vulnerability in a web application. Various parameters are applied for uses depending on the web application, determining the vulnerable parameter can only be achieved through inspecting parameters with their functioning. A parameter may represent a section of user profile, picture, comment, permissions, or department of a personal account. 

     2. Source code Review 

Instances where direct object reference is applied can be determined through source code review which will enhance chances of detecting a direct reference point. As idor is difficult to determine from automated methods, source code review not only helps attackers but also developers to determine where the direct references to internal resources are mapped. 

This includes,  

  1. Sequential ids 
  1. Hashed values 
  1. Account parameters. 

Consider an example of  

<ul class="Idor Example"></ul>  
<h2 class="charset">Welcome! </h2> 
<div id="menu"></div> 
<ul class="Idor detection"></ul> 
<div id="posts"> 
<div id="post_1" class="post clearfix"> 
<a class="post-archive" name="post-3587"></a> 
<div class="pull-left"></div> 
<div class="pull-right"></div>

The “post-3587” contains numeric valued parameter. In this manner IDs can be detected in source code as well. 

3. Manual Testing with various accounts. 

Interchanging the ids from more than one account leads not only to deep understanding of the web application but also allows you to create scenarios to exploit Idor. Using multiple accounts, it is possible to detect idors and parameters which may be vulnerable to these kinds of exploitation. The more you observe request parameters, the more the chance of finding user_ids and file_ids allowing attacker to exploit web application. You can use normal browser tab as an user and incognito mode an attacker to reduce time. 

 If the identifier value is hashed, you can use several decoding techniques to bypass it. 

IDOR Types 

There are various Idor types depending on the way they are exploited and the basic nature of the operation. 

  1. Manipulation of the body and URL Tampering Attacks 

 This type of IDOR attack involves gathering information from other users by modifying the value of input fields. Attackers change URL parameters on the client-side. URL tampering attacks target the GET and POST parameters because they are susceptible to contamination of URL parameters. 

 2. Manipulating JSON IDs  

JSON is a widely used format for data exchange between hosts. JSON data sent between APIs, servers, and web applications may be intercepted by an attacker. If the Jason data provides the predictable values sent between APIs, servers and web application, alteration of such data causes direct call to server resources as there are no temporary replacements for server resources in case of the exploitable application.  Thus, opening the door for Idor. Json ID example 

"name":"Kane Root",  
"email":[email protected], 

3. Mass Assignment and Obtaining unauthorized data access 

Applying an Idor  attacker may access data on a larger scale, for example getting sensitive information about every user available. An attack is performed when an attacker is granted access to an internal object reference and can change the basic details of application data.Actions such as storing crucial details on the user’s database or taking control over user information fall under this type of attack. The IDOR attack type involves controlling user credentials such as API keys, commands, and user ID parameters so the attacker can operate illegally in the targeted application.  

4.‍ Allowing file access 

This IDOR type interacts with path traversal and permits an attacker to do easy file resource manipulation. Attackers can walk through numerous sensitive files by just replacing the file name. The URL 

Contains direct Reference to the object mapped internally. In the case of decryptable hash value or predictable sequence, path traversal with idor can be applied. 

5. Blind Idor 

Server response does not return the details or validation of the exploitation by the attacker, but the attack impacts the victim. In this case you will not be able to confirm the success of IDOR through HTTP response. The usual validation does not take place in the blind idor scenario instead information can be fetched from emails, export files or text alerts. 

So, this is how Idors can be distinguished from one another depending upon the server response and the overall impact of the attack. 

Idor Attack Scenarios and bypassing techniques  

The testing of Idor is done at the instances where the user is commanding a database or accessing files to fetch resources or perform related actions. Examples include 

Idor Attack scenario
  1. Parameter Fetching database resources 

In many instances, user records are altered or created by web application using parameters which unquietly identifies these account generating requests and if this parameter applies sequencing or numbering them it is easier to access other accounts as well. The user is trying to fetch a record

The user input can retrieve records from other users by changing the “num” parameter.  

2. Parameter Fetching File Resources 

When critical resources are stored in static files on the server-side filesystem, IDOR vulnerabilities are common. A site uses

that is used to fetch a file within the database. The user input is directly taken to fetch the file within the system. Similarly, by changing the file name, as it is a number, to retrieve credentials and other sensitive data. 

3. Parameter performing an operation 

In these cases, the operations related to a particular user are carried out through the input parameter and request body which can be delete, update, create, etc. The example,

, shows that we can perform update action related to any user.  

4.Placing ids to requests without ids 

Even if the request URL is not using input parameters, place parameters to each request and observe whether it is making any difference. For example, if this request displays all your card details: 

GET /api/card 

What will happen if the attacker appends the user id as mentioned below?   

GET /api/card?custom_id=<victim_id>

Even if web applications sometime hide information related to parameters, by observing the adjacent requests, you can add ids randomly. 

5. Parameter Pollution 

By supplying multiple values for a single parameter, one may create a scenario where idor can be exploited. Change request from 

 GET /api/card?custom_id=<attacker_id>   


GET /api/card?custom_id=<attacker_id>&custom_id=<admin_id>  


GET /api/card?user_id=<admin_id>&custom_id=<attacker_id> 

6. Replacing keywords with Reference ids 

Consider a scenario where the web application uses keywords such as “user/self/customer” and uses reference_id occasionally based on the request that is being made, simply replace the keyword with reference_ids . For example, replace  

GET /profile/update/user/ 


GET /profile/update/self/ 


GET /profile/update/14456/

7. Appending special characters and random strings 

Simply replacing ids might get you a 401, access denied or invalid request. So, in this case appending special characters (/) or strings such as %20, %1e, etc. might give you an Idor. Turn request from 

GET /profile/update/14456/ 


GET /profile/update/14455%1c

This may break the application’s logic. 

8. Replacing methods and Content type 

Changing methods may allow you to conduct Idor validation as you should interchange methods GET, POST, PATCH, OPTIONS and DELETE if either of them fails. In most cases, just changing or replacing the ids is not enough, you must keep changing request methods in order to bypass prevention techniques.  

Change request from 

POST /2/account/Accounts/1234 HTTP/1.1
Content-Length: 36
Connection: close
[email protected]


PUT /2/account/Accounts/1233 HTTP/1.1  
Content-Length: 36  
Connection: close  
[email protected] 

Modifying request file type can also be helpful in finding Idors. Altering file type at the end of URL is an example of such case. For example, changing the file name to. Json at the end of the URL or header. 

Original Request          

POST /api/contact/allow/435 
Content-type: application/xml  

Modified Request 

POST /api/contact/allow/123 
Content-type: application/json 
{“account”: “test”} 

9. Encoded and hashed values 

Most web applications use known encoding schemas which allow attackers to decode them easily. In instances where the id is randomized or encoded, you can check whether it is predictable. Try creating multiple accounts as it will allow you to understand the id randomization. Api endpoints sometimes leak the hashed ids in other user requests. 



account_id= 5678 

These are some cool tricks which will guide you in getting an Idor. 

Best Way of Finding Idor 

To automate the process of finding Idor,  Firefox Multi-Account Containers  

And Burp extension Autorize are used, let us see how to use them.

Multi account container 

This add-on lets you create multiple accounts in a single window. 

  1. Visit  Firefox Multi Account Container
  1. Add the extension to Firefox. 
  1. Choose extension from the top right and select account type as shown below. 
Multi Account Container
  1. This will allow you to intercept all the requests in the burp from various accounts on the same window.  

Finding Idor certainly becomes easier with this technique. 

Moving on to the Autorize, 


This burp extension allows you to repeat each request just by replacing cookies from one user to another reducing the time consumption that takes place in manual work, helping the penetration tester to detect authorization vulnerabilities. 

  1. Before installing the autorize, configure Jthon environment int the 


Jthon Path
  1. Install autorize from Autorize Github. or
  1. After Installation, the right side contains request and response and the left one contains the configuration section such as “scope items only”. 
  1. Now, from your burp repeater or proxy tab, copy the cookies and place them in authorize tab.
Autorize Configuration

That is, you need to surf all possible account actions to test every functionality in the web application. 

6.Autorize will reply in three ways 

a. Bypassed! – Red color 

b. Enforced! – Green color  

c. Is enforced? (Check it manually) – Yellow color 

Autorize Demo

Thus, Autorize + multi-account container can give you easy Idor . 

Implications of Idor  

Critical functionalities, if vulnerable to idor lead to severe impact, it totally depends upon the functionality which is being exploited. Some major impacts of idor are mentioned below. The highest impact is inevitable if the functionalities such as account recovery, password reset, password change and changing security questions are affected by this type of vulnerability. If the application only allows reading permissions, then also by exposing sensitive information on the client side. 

Impact of Idor (

Exposed object references and client-side response may reveal sensitive information which in turn can be used to build injection payloads which will lead to further exploitation. Server-side files used in usual operational process and referred through reference id, just by modifying the file name, you can surf through various server files which allows static file access. 

In some cases, you will find idor functionalities such as storing comments on victim account, such action itself is not impactful but if combined with self xss which will be sent to victim as stored xss leads to major impact. Modifying confidential data to get horizontal and vertical privilege escalation which will allow action beyond the scope of the attacker account and bundle information on to client-side responses. 


We have covered detection and exploitation part of Idor , now it’s time to cover some useful prevention techniques to avoid Idors in your web application. 

Idor Prevention (

Use an Indirect Reference Map 

The first approach is to replace all the direct object references such as user ids, key, names, etc. with the indirect object references which will be mapped directly to the rest of the internal objects. These client-side indirect ids can be mapped internally to direct objects present on the server side after the temporary substitution. 

Implement Access Control 

Servers refrain from validating resource sharing at the time attacker tampers the url on to the client side. This happens as there are no access control checks applied on the server or there is no process of validating if the user has or should be granted access to a particular resource or information. 

Unpredictable references 

Maintaining validation of parameters and using unpredictable and random variables as input reference that is difficult to anticipate for an attacker and thereby reducing risk of malicious request being crafted by the attacker. Hashed values and encoding that can be predicted by the server not by any decoding or manual guess by end-users.  

Development process to avoid leaking Private references 

Developers occasionally leak direct or private references which then can be observed through bundled responses at the time of execution of that request in which the private reference is exposed. Automated scanners should be avoided, and source code review should be preferred. 

Avoid using Sequential UUID 

Sequential use of direct object references makes it simple for an attacker to predict and scrap through all resources without any difficulty. Creating substituted random values, encode and hashed, reduces the impact caused from insecure object references. 

Thus, the above-mentioned prevention techniques narrow down the scope of attack and reduce major impact from insecure direct object reference. Also visit to get more prevention techniques. 


In conclusion, Idor is one of the most found vulnerabilities in web applications and the simple reason for that is automated tools lack in detecting Idor. Manual Testing is essential for detecting Idor comprehensively. Even if some tool can detect it, it must be inspected again to validate. Privilege escalation, both vertical and horizontal, comes into picture in case of Idor. Using multiple accounts enhances possibilities of finding Idor. The more you observe the more you get close to finding Idors. Just replacing one user id with another is not the only way to find Idor, replacing methods, file types and appending strings to break the logic of web application must be validated. Attaching Idor with different vulnerabilities such as account takeover and privilege escalation can result in catastrophic damage for an organization. But you can avoid all this if preventions are considered like using indirect object references and maintaining a strong access control. Thus, Idors  are catastrophic vulnerability that affects confidentiality of a web application which can be avoided by access control checks, session management and substituted indirect references.  

Get some practice resources from  Portswigger

Here are some references: 

1. Rise of Idor by Hackerone

2. How To find Idor by Bugcrowd 

3. Insecure Direct Object Reference by Intigrity 

4. Intro-to-idor by Vickieli 

5. IDOR by Thái Vũ 

6. Understanding IDOR by Appknox 

7. Idor by 

8.Finding more Idor by Aon 

9.Autorize by Yeswehack 

Also read our previous blog here!!!

Leave a Reply

Your email address will not be published.