Exposing the invisible: Practical IDOR exploitation for beginners

Introduction

In this article, I’ll walk you through two practical ways to exploit IDOR (Insecure Direct Object Reference).

IDOR is a widespread vulnerability that falls under BOLA(Broken Object Level Authorization), which has consistently ranked among the OWASP Top 10 web application risks.

We’ll be using Burp Suite and FoxyProxy to demonstrate IDOR in a real scenarios and show you how easy it is to leak data when proper access control is not implemented on a web application.

Tools You’ll Need

• Burp Suite – To intercept and modify HTTP requests. [download at https://portswigger.net/burp]

• FoxyProxy – A browser extension to route your browser traffic through Burp.

• Postman/Browser – To craft and send our web requests.

---

What is IDOR (Insecure Direct Object Reference)?

IDOR is a type of access control vulnerability that occurs when an application exposes internal object references (such as their document, IDs, or invoice numbers) in a way that allows attackers to manipulate them and access unauthorized data.

IDORs can affect resources other than database objects. Another type of IDOR happens when applications reference a system file directly. For example, this request allows users to access a file they’ve uploaded: https://.../uploads?file=user1234-01.jpeg. Since the value of the file parameter is user1234–01.jpeg, we can easily deduce that user-uploaded files follow the naming convention of USER_ID-FILE_NUMBER.FILE_EXTENSION. Therefore, another user’s uploaded files might be named user1233–01.jpeg. If the application doesn’t restrict user’s

If you've ever tried changing a number or string in your browser’s address bar and suddenly saw another user’s profile or files, then you’ve encountered an IDOR vulnerability. And it’s is extremely common .

We will testing against a vulnerable site the two methods we will be using are

• Manually changing parameter using burp suite

• Automatically manipulate input parameter with ffuf.

Method 1

We will be using vulnerable sites in this article, first one is portswigger lab available at [https://portswigger.net/web-security/access-control/lab-insecure-direct-object-references] if you want to follow along it really easy and it will give you a good grasp of the concept.

You'll need to install Burp's certificate and configure FoxyProxy. First, launch Burp and visit http://burpsuite in your browser. Download the certificate and install it in your browser’s authorities store (under Settings > Certificates). Next, install the FoxyProxy extension and create a profile just like the one in the image below.

Open Burp suite. Go to the Proxy > Intercept tab.

Set the intercept toggle to Intercept on.

Visit https://portswigger.net/web-security/access-control/lab-insecure-direct-object-references Interact with the application, clicking the View transcript button will download a text file containing the chat you just had.

In the screenshot below

• A GET request is made to /download-transcript/2.txt.

• Burp shows a 200 OK response, meaning the file is accessible.

• The file contains a private chat transcript.

• Changing the ID from 2.txt to 1.txt, 3.txt, etc., could reveal other users’ data — this confirms an IDOR.

1. Right-click the intercepted /download-transcript/2.txt request → Send to Intruder.

   In the Positions tab:

Select the Intruder→Positions tab to select the payload positions. Firstly, select Clear § to remove the automatic payload positioning. Then select the number at the end of the URL and click the button labeled Add §, once you’ve selected the attack position [highlighted in the image above ] select the Payload tab

1. Go to Payloads tab:

   • Set payload type to Numbers from 1 to 5.

2. Start the attack — each request tries a new file ID, looking for valid files.

1. Copy the password from the other transcript you find

2. Go back to the application sign in

   • with username carlos and the password you just found

Method 2 :Using ffuf to automate:

Tools You’ll Need

• ffuff: is an open-source Python-based web application fuzzing framework. It comes with newer versions of kali linux. it can test hundreds of ID’s quickly

ffuf options -w payload.txt -u "URL"

ffuf -w /usr/share/wordlists/dirb/common.txt -u "https://example.com/download-transcript/FUZZ.txt"

• -w: path to your wordlist.

• FUZZ: the injection point for ffuf to replace with words or numbers.

Real-world Application:

In the real world modern website can use a unique, unpredictable key or a hashed identifier to reference each user’s resources. For that reason IDORs are not always as simple as switching out a numeric ID.

At the end of the article we will be looking for some ways to handle those edge cases.

How do we prevent IDOR in applications ?

IDORs happen when an application fails at two things. First, it fails to implement access control based on user identity. Second, it fails to randomize object IDs and instead keeps references to data objects, like a file or a database entry, predictable.

1. Application should check the user’s identity and permissions before granting access to a resource.

2. The website can use a unique, unpredictable key or a hashed identifier to reference each user’s resources. Hashing refers to the one-way process that transforms a value into another string. Hashing IDs with a secure algorithm and a secret key makes it difficult for attackers to guess the hashed ID string resulting to URL’s that look like https://example.com/?user_key=6MT9EalV9F7r9pns0mK1eDAEW

Bypassing IDOR Protection:

Encoded or Hashed URL

In your bid to find vulnerabilities you will come across URL with a seemingly random string, always suspect that it is encoded URL different schemes (URL encoding, HTML encoding, hex encoding, octal encoding, base64, base64url, and so on) to figure out the encoding scheme in use. Do not give up on such URL’s faced and try to decode it.

An Application with that does no t use ID’s to reference objects

In modern web applications, you’ll commonly encounter scenarios in which the application uses cookies instead of IDs to identify the resources a user can access.

Since you don't know another user's session cookies, it might seem like the application is safe from IDORs. However, some applications use object IDs to retrieve resources. They might do this for developer convenience, backward compatibility, or because they forgot to remove a test feature. If no IDs are present in the application-generated request, try adding one with keywords like user_id or message_id to the URL query and see if it changes the application's behavior.

Change the Request Method

If one HTTP request method doesn’t work, you can try others: GET, POST, PUT, DELETE, PATCH, and so on. Applications often allow multiple request methods on the same endpoint but may not apply the same access control for each method. For example, if a GET request is not vulnerable to IDOR and doesn’t return another user’s resources, other methods might.

Change the Requested File Type

Changing the file type of the requested file can sometimes cause the server to handle authorization differently. Applications might let users identify information in different ways: either by using IDs to reference a file or by using the filename directly. However, they often fail to apply the same access controls for each method of reference. For instance, applications commonly store information in JSON file types. Try adding the .json extension to the end of the request URL and see what happens.

Conclusion: How to Hunt for IDORs in the Real World

When testing for IDOR vulnerabilities in real-world applications, follow this four-step approach:

Step 1: Create multiple accounts on target application

Create two or more user accounts (with varying permission levels, if applicable). Use one as the attacker and the other as the victim. Compare behavior when switching out IDs like user_id=1235 vs. user_id=1236. If the app restricts account creation, consider reaching out to the company for extras, especially if participating in a bug bounty program.

Step 2: Explore Application Features

Map out as many features as possible, especially those that return or manipulate user data (e.g., messages, file uploads, group access). These are prime candidates for IDOR vulnerabilities.

Step 3: Intercept and Analyze Requests

Capture all requests using Burp Suite or your preferred proxy tool. Pay attention to parameters like IDs in URLs, request bodies, headers, cookies, and file paths. Use two browsers (or sessions), logged in as attacker and victim, to monitor the effects of manipulated requests in real time.

Step 4: Modify Object References

Finally, try changing identifiers in requests—swapping user_id, message_id, file, or group values—and observe if unauthorized access or changes are possible. Successful tampering confirms the presence of an IDOR vulnerability.