Insecure Direct Object Reference (IDOR)

In this chapter, we are going to learn about insecure direct object reference vulnerabilities (or also called IDORs).

Type of vulnerability: Server-Side

Chances to find: Very High; IDOR is part of “Broken Access Control” ranked #1 in the “OWASP Top-10 Vulnerabilities

TL;DR: An IDOR vulnerability enables an attacker to request a resource that belongs to a different entity by solely knowing the identifier (e.g. a document ID)

What is an IDOR?

Insecure Direct Object References (IDOR) occur when an application provides direct access to objects based on user-supplied input. As a result of this vulnerability attackers can bypass authorization and access resources in the system directly, for example database records or files. Insecure Direct Object References allow attackers to bypass authorization and access resources directly by modifying the value of a parameter used to directly point to an object. Such resources can be database entries belonging to other users, files in the system, and more. This is caused by the fact that the application takes user supplied input and uses it to retrieve an object without performing sufficient authorization checks. (src: OWASP)

Let’s have a look at an example. Imagine you are using a document sharing platform. You can upload an important document and share it with another person. A common use case could e.g. be that you want to share your CV (containing personal data) with your future employer.

 An example HTTP request to retrieve the file could look like this:

GET /document/sharing?docID=1337 HTTP/1.1
Host: example.com

An attacker could now try to enumerate the “docID” request parameter. Using an automated tool, he/she could e.g. try to start querying a “docID” of 0 all the way up to a very high number within minutes.

Question the IDOR’s impact!

With insecure direct object reference vulnerabilities, it’s sometimes easy to miss that some enumerability might be by design. Think of the above example once again. It could e.g. be that the application is not meant to store any secrets. There might be an overview of all files available where you can simply access the file with its right ID anyway.

Always ask yourself is, is this really an issue or is it intended behaviour? Is there any security impact looking at the entire application?

Some examples of people who misunderstood the behaviour of the application:

It’s also important to evaluate if the reference to an object is actually guessable or easy to enumerate. A lot of web applications use UUIDs as the de facto standard for identifiers. These IDs are not easily guessable. Creating a submission would only be acknowledged as security vulnerability if the UUID of an otherwise unknown document is disclosed somewhere else on the application.

The impact of IDORs!

The impact of an insecure direct object reference vulnerability depends very much on the application’s functionality. Therefore, a clear list can not be easily given. Generally speaking, an IDOR vulnerability can introduce a risk for CIA (confidentiality, integrity, availability) of data.

Here are some public write-ups of IDOR vulnerabilities exploited in the wild:

How to prevent IDORs?

The best way to prevent IDOR vulnerabilities is to implement strict access control checks on every functionality to see if the user is authorized to access and/or manipulate the requested object.

Find out more information about IDOR prevention in OWASP’s IDOR prevention cheat sheet.

Additional resources:

Let’s have a look at a video example of an IDOR vulnerability:

This video by PwnFunction gives a very good visual explanation of IDORs:

Following links are valuable to learn more about IDORs: