Post cover image

March 15, 2026

Web Security Series #4 — Discovering Unauthorized Resources via IDOR (Burp Suite & ffuf)

Access control mechanisms are a fundamental component of web application security. When implemented incorrectly, they can allow attackers…

By Laibakashif

5 min read

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=1009

If 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:

  1. Manual testing and automation using Burp Suite
  2. 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=1009

The identifier 1009 corresponds to a user named issabelle.

None

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 History

Locate the GET request containing the parameter:

account=1009
None

Send the request to Repeater for testing.

None

Step 2 — Test Manual ID Manipulation

In Burp Repeater, modify the ID value to another number.

Example:

account=1009 → account=1001

Send 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.

None

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 → Positions

Highlight the numeric identifier and mark it as a payload position.

None

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.py

This 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.

None

Step 6 — Filter Responses for Admin Accounts

After the attack completes, filter responses by searching for keywords such as:

admin
role: admin
isAdmin

In this lab, the enumeration revealed a privileged account with ID:

account=1008

Opening this URL in the browser confirmed access to an administrator account.

None

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.py

This 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:

  • -u specifies the target URL
  • FUZZ indicates where the wordlist values will be inserted
  • -w numbers.txt loads 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 = 1008

Opening this ID in the browser revealed an administrator account.

None

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