Introduction

Applications now rely heavily on APIs to exchange data between mobile applications and web services. While APIs improve functionality and integration, they can also introduce security risks if not properly designed. One of the most common vulnerabilities tested during API penetration testing is Insecure Direct Object Reference (IDOR), also known as Broken Object Property Level Authorisation in the API world.

IDOR occurs when an application uses user-supplied input to directly access data or resources without proper authorisation checks. Attackers exploit this by manipulating identifiers (e.g., changing id=100 to id=102 in a URL or API request) to view, modify, or delete another user's private data. Understanding how this vulnerability occurs and how attackers think when exploiting it is essential for improving API security.

How the Vulnerability Occurs in APIs

IDOR vulnerabilities occur when an API allows users to directly access resources using identifiers without properly validating their authorisation. In many systems, APIs rely on parameters such as user IDs or order IDs to retrieve data from a database. If the API only checks whether the user is authenticated but does not verify whether they are authorised to access that specific object, unauthorised data access can occur.

For example, consider a hypothetical API endpoint:

GET /api/users/101/account

This request retrieves the profile information of a user with the ID 101. If the API does not verify whether the authenticated user actually owns or has permission to access this profile, an attacker could simply modify the ID:

GET /api/users/102/account

If the application responds with another user's account information, it indicates the presence of an IDOR vulnerability.

Practical Scenario Using VAPI

API 1- Broken Object Level Authorisation (BOLA)

Description: The API fails to perform proper authorisation checks, which will allow an attacker access the data of other users. A user, A, can access another user, User B's information and also update another user's information and vice versa. I found out that the APIs access user data by using a user id as an identifier. This identifier can be predicted and replaced by an attacker because it's incremental, e.g., 1, 2, 3 …

How Found

Endpoints exploited

GET http://{{host}}/vapi/api1/user/{{api1_id}}

PUT http://{{host}}/vapi/api1/user/{{api1_id}}

Step 1: Create two user accounts POST http://{{host}}/vapi/api1/user

Did this by sending a POST request to vapi/api/user

Step 2: Retrieve the user's details, i.e., the user IDs and authorisation tokens

From this, I see that the application uses incremental values, e.g., 5, 6, etc., which is a bad security posture.

Step 3: Getting User

Now let's send the Get User request. This returns some data on the user we just created.

Next, proxy this request into Burp Suite and send it to Repeater.

Firstly, I set my Postman to proxy traffic to Burp Suite

Under Proxy Setting for Burp Suite, I set the 127.0.0.1:8080

Changing the ID to 5, which is for user A, we created retrieves user A

Proceed to check if I can get a random user, knowing the Ids are incremental retrieves the information of another user.

Here, we are retrieving data for a different user. This is a classic example of a BOLA vuln.

Now, let's see what happens if we try with an ID value of 1, as we may speculate that the first user to be created may well be the admin user.

Here, we are getting the data of yet another user, along with the flag for this task:

Flag 1: flag{api1_d0cd9be2324cc237235b

Potential Impact if Exploited

If exploited, IDOR vulnerabilities can have serious consequences for organisations and users. Possible impacts include:

• Exposure of sensitive user information, such as PIIs.
• Unauthorised access to financial or transaction records.
• Data manipulation, where attackers modify or delete resources belonging to other users.
• Large-scale data harvesting through automated requests.

Why APIs Are Especially Vulnerable

APIs are particularly vulnerable to IDOR vulnerabilities because they often expose structured endpoints that directly reference backend objects. Unlike traditional web applications, where access controls may be implemented at multiple layers, APIs frequently rely on simple request parameters to fetch resources.

How Developers Can Prevent IDOR

Some key prevention strategies include:

• Implementing proper access control checks to verify that users can only access resources they own or are authorised to view
• Using indirect references or randomised identifiers instead of predictable sequential IDs like 1, 2 …
• Enforcing role-based or attribute-based access control mechanisms
• Conducting regular security testing and API penetration testing to identify access control weaknesses