Introduction
Insecure Direct Object References (IDOR) is a type of access control vulnerability that arises when an application uses user-supplied input to access objects directly. If the application does not adequately verify whether the user requesting the object is authorized to access it, an attacker can manipulate the reference (such as a database ID, file name, or user ID in a URL) to access other users' sensitive data.
The important distinction is that the reference itself is not the vulnerability. The vulnerability is trusting that reference without checking whether the current user should be allowed to follow it.
In this lab, you will act as a security tester evaluating a local web application API. You will start by authenticating as a standard user, analyzing how the application references your user profile, and then exploiting an IDOR vulnerability to access the private data of other users, including an administrator.
Authenticate as a Standard User
In this step, you will interact with a local web API running on your machine at port 5000. To begin testing the application for vulnerabilities, you first need to authenticate as a standard user to obtain a valid session token.
We have been provided with the credentials for a standard user named Alice. Her username is alice and her password is password123.
You will use the curl command-line tool to send an HTTP POST request to the login endpoint. curl is a powerful tool used to transfer data to or from a server.
Run the following command in your terminal to log in:
curl -X POST http://localhost:5000/api/login \
-H "Content-Type: application/json" \
-d '{"username": "alice", "password": "password123"}'
Let us break down this command:
-X POSTspecifies that we are sending a POST request, which is typically used for submitting data like login credentials.-H "Content-Type: application/json"tells the server that the data we are sending is formatted as JSON.-d '...'contains the actual JSON data payload with the username and password.
If the credentials are correct, you should see an output similar to this:
{"token": "Bearer alice_token", "user_id": "1001"}
Take note of the token and the user_id. The token (Bearer alice_token) acts as your digital ID card. You will need to include it in future requests to prove you are authenticated. The user_id (1001) is your unique identifier in the application's database.
Analyze Object References (URLs/APIs)
Now that you are authenticated as Alice, you can access her user profile. In many web applications, user profiles are accessed via an API endpoint that requires your authentication token and a reference to the specific object (in this case, the user profile) you want to view.
You will use curl again, but this time you will send a GET request to the /api/profile endpoint. You must include the authentication token in the HTTP headers and specify your user_id in the URL.
This is exactly the kind of pattern that shows up in real APIs: a token proves the session exists, while a parameter selects the object to fetch. Secure applications must bind those two ideas together with authorization checks.
Execute the following command to view Alice's profile:
curl -H "Authorization: Bearer alice_token" \
"http://localhost:5000/api/profile?user_id=1001"
In this command:
-H "Authorization: Bearer alice_token"passes your digital ID card to the server.?user_id=1001is a query parameter appended to the URL. This is the Direct Object Reference. It tells the server exactly which database record to fetch.
You should receive a JSON response containing Alice's profile information:
{"name": "Alice", "role": "user", "email": "alice@example.com", "secret": "alice_secret_123"}
Notice how the application relies on the user_id=1001 parameter in the URL to decide which data to return. A secure application would verify that the user associated with the Bearer alice_token is actually allowed to view the data for user_id=1001. If the application fails to perform this authorization check, it is vulnerable to IDOR.
Manipulate User IDs
In this step, you will test if the application properly enforces access controls. You are currently authenticated as Alice, but what happens if you ask the server for another user's data?
That is the core authorization question. "Am I logged in?" and "Am I allowed to read this object?" are different checks, and confusing them leads directly to IDOR.
Let us assume there is another standard user named Bob, and his user ID is 1002. If the application is vulnerable to IDOR, it will blindly trust the user_id parameter in the URL without checking if Alice has the permission to view Bob's profile.
Modify the user_id parameter in your previous command from 1001 to 1002. Run the following command:
curl -H "Authorization: Bearer alice_token" \
"http://localhost:5000/api/profile?user_id=1002"
Observe the output returned by the server:
{"name": "Bob", "role": "user", "email": "bob@example.com", "secret": "bob_secret_456"}
You have successfully retrieved Bob's private information, including his email and secret key, while still authenticated as Alice!
This confirms the presence of an Insecure Direct Object Reference (IDOR) vulnerability. The server checked that you were logged in (by validating the token), but it failed to check if you were authorized to access the specific object (Bob's profile) you requested.
Access Unauthorized Data
Having confirmed the IDOR vulnerability, you can now escalate the attack to access highly sensitive information. In many systems, administrative users have predictable IDs, such as 1, 0, or 9999.
For this application, the administrator's user ID is 9999. By exploiting the same IDOR vulnerability, you can attempt to extract the administrator's profile, which contains a secret flag.
To document your finding, you will redirect the output of your curl command into a file named flag.txt within your current working directory (~/project).
Run the following command to fetch the admin's profile and save it:
curl -H "Authorization: Bearer alice_token" \
"http://localhost:5000/api/profile?user_id=9999" > ~/project/flag.txt
The > symbol redirects the output that would normally print to your screen into the specified file.
To verify that you have successfully captured the administrator's data, read the contents of the file using the cat command:
cat ~/project/flag.txt
You should see the administrator's profile data, including the secret flag:
{"name": "Admin", "role": "admin", "email": "admin@example.com", "secret": "FLAG{IDOR_VULN_EXPLOITED}"}
Congratulations! You have successfully exploited an IDOR vulnerability to bypass access controls and retrieve sensitive administrative data.
Summary
In this lab, you explored the mechanics of Insecure Direct Object References (IDOR), a critical access control flaw. You started by authenticating as a standard user and analyzing how the application referenced user data via URL parameters. By manipulating these parameters, you successfully bypassed authorization checks to view the private profiles of other users. Finally, you escalated the attack to extract sensitive administrative data.
This exercise highlights the importance of implementing robust authorization checks on the server side. Applications must never rely solely on user-provided input to grant access to objects; they must always verify that the authenticated user has the explicit right to access the requested resource.
