Access control mechanisms are a fundamental component of web application security. When implemented incorrectly, they can allow attackers to access resources that should be restricted. One of the most common vulnerabilities related to broken access control is Insecure Direct Object Reference (IDOR).
In this write-up, I demonstrate how an IDOR vulnerability can be exploited to access unauthorized user accounts by manipulating object identifiers. The lab illustrates how attackers can enumerate resource IDs and discover privileged accounts using both Burp Suite and the ffuf fuzzing tool.
This article is part of my Web Security Series, where I document hands-on labs and practical techniques used during web application penetration testing.
Understanding Insecure Direct Object Reference (IDOR)
An Insecure Direct Object Reference (IDOR) occurs when an application exposes internal object identifiers such as account IDs, file numbers, or invoice identifiers and uses them directly to retrieve resources without enforcing proper authorization checks.
For example, a web application may include a parameter like:
account=1009If the server simply retrieves the account associated with this identifier without verifying whether the requesting user is authorized to access it, attackers can manipulate the ID to access other users' data.
This type of vulnerability can lead to horizontal privilege escalation (accessing other users' data) or vertical privilege escalation (accessing administrative resources).
When This Attack Technique Is Used
Testing for IDOR vulnerabilities is commonly performed during the reconnaissance and exploitation phases of a penetration test.
It becomes relevant when:
- Resource identifiers appear in URLs or parameters (e.g.,
account=1009,invoice_id=42). - Identifiers are predictable or sequential.
- The application does not enforce strong access control checks on server-side requests.
When these conditions exist, attackers can attempt to enumerate object identifiers to identify sensitive resources such as administrator accounts.
Lab Objective
The objective of this lab is to:
Enumerate object identifiers to discover accounts that should not be accessible, specifically administrative accounts.
Two different techniques are demonstrated:
- Manual testing and automation using Burp Suite
- Automated enumeration using the ffuf fuzzing tool
Lab Environment
The application exposes an account parameter in the URL:
http://127.0.0.1/labs/e0x02.php?account=1009The identifier 1009 corresponds to a user named issabelle.

Because the application relies on numeric account identifiers, it becomes possible to test whether other IDs expose additional accounts.
Method 1 — Exploiting IDOR Using Burp Suite
Burp Suite allows testers to inspect, manipulate, and automate HTTP requests. In this lab, Burp is used to identify and enumerate account identifiers.
Step 1 — Identify the Target Request
Open Burp Suite and navigate to:
Proxy → HTTP HistoryLocate the GET request containing the parameter:
account=1009
Send the request to Repeater for testing.

Step 2 — Test Manual ID Manipulation
In Burp Repeater, modify the ID value to another number.
Example:
account=1009 → account=1001Send the request and inspect the response.
If the server returns data for another user, it indicates that the application retrieves records solely based on the provided ID.

In this case, the response returned a different user account (Alice), confirming that the ID parameter controls which user record is retrieved.
Step 3 — Automate Enumeration with Intruder
To automate the process, send the request to Burp Intruder.
Navigate to:
Intruder → PositionsHighlight the numeric identifier and mark it as a payload position.

Step 4 — Create a Numeric Wordlist
Instead of manually testing IDs, create a wordlist containing sequential numbers.
Example Python script:
# create_numbers.py
with open("numbers.txt", "w") as f:
for i in range(1, 5001):
f.write(str(i) + "\n")
print("File created successfully: numbers.txt")Run the script:
python3 create_numbers.pyThis generates numbers.txt containing IDs from 1 to 5000.
Step 5 — Launch the Intruder Attack
Load the generated wordlist into Intruder and start the attack.
Burp will automatically send requests with each ID.

Step 6 — Filter Responses for Admin Accounts
After the attack completes, filter responses by searching for keywords such as:
admin
role: admin
isAdminIn this lab, the enumeration revealed a privileged account with ID:
account=1008Opening this URL in the browser confirmed access to an administrator account.

Method 2 — Exploiting IDOR Using ffuf
While Burp Suite provides a graphical interface for testing, similar enumeration can also be performed using ffuf, a fast command-line fuzzing tool.
Step 1 — Generate a Numeric Wordlist
As before, generate a list of IDs using the Python script:
python3 create_numbers.pyThis creates numbers.txt containing sequential IDs.
Step 2 — Run ffuf to Fuzz the Account Parameter
Use ffuf to test the account parameter automatically.
Example command:
ffuf -u 'http://192.168.57.139/labs/e0x02.php?account=FUZZ' \
-w numbers.txt \
-mr 'admin'Explanation:
-uspecifies the target URLFUZZindicates where the wordlist values will be inserted-w numbers.txtloads the ID wordlist-mr 'admin'filters responses containing the word admin
Step 3 — Analyze the Results
ffuf returns IDs whose responses match the filter.
In this lab, the tool discovered:
account = 1008Opening this ID in the browser revealed an administrator account.

Why This Vulnerability Occurs
IDOR vulnerabilities occur when applications rely on client-supplied identifiers without verifying authorization on the server side.
Instead of validating whether a user has permission to access a resource, the application directly retrieves data based on the provided identifier.
This allows attackers to enumerate resources simply by modifying IDs.
Security Impact
IDOR vulnerabilities can lead to:
- Unauthorized access to sensitive user data
- Exposure of administrative accounts
- Horizontal and vertical privilege escalation
- Data leakage and privacy violations
Broken access control vulnerabilities are consistently ranked among the most critical web security risks, including in the OWASP Top 10.
How to Prevent IDOR Vulnerabilities
Developers can mitigate IDOR vulnerabilities by implementing strong access control checks.
Recommended practices include:
- Verifying authorization on the server for every request
- Avoiding direct exposure of internal identifiers
- Using indirect reference maps instead of raw IDs
- Implementing role-based access control
- Logging and monitoring abnormal access patterns
These measures ensure that users cannot access resources outside their authorized scope.
Conclusion
This lab demonstrated how Insecure Direct Object Reference (IDOR) vulnerabilities can be exploited to access unauthorized resources.
By enumerating numeric identifiers using Burp Suite Intruder and ffuf, it was possible to discover an administrator account that should not have been accessible.
Understanding these attack techniques helps security professionals identify weak access control mechanisms and design more secure web applications.
Acknowledgment
This work and learning process would not have been possible without the mentorship and guidance of my tutor, whose support and insights have greatly contributed to my understanding of web application security.
Connect With Me
If you found this write-up helpful, feel free to connect and follow my cybersecurity learning journey.
🔗 LinkedIn: www.linkedin.com/in/laibakashif0011