How I Found an IDOR Vulnerability in a Local News App and What You Can Learn From It

Hey folks! It’s been a while since I last wrote a blog, but I’ve got something interesting to share this time. You know, as a pentester, I’m always on the lookout for potential targets during my everyday browsing. This time, the story starts on Instagram (of all places). I came across an app ad — it’s one of those local news and activity apps, you know the type that tells you what’s happening around your area, from events to daily updates.

Curious, I decided to check it out. The app had a web version too, so I started exploring. While surfing through user profiles, I noticed something that immediately caught my eye: the URL structure had a user ID in it. As many of you in the security field might know, seeing something like /api/users/12345 in the URL is often a telltale sign of potential Insecure Direct Object Reference (IDOR) vulnerabilities. I couldn’t resist digging deeper—time to fire up Burp Suite and see what’s really going on behind the scenes.

In this blog, I’ll walk you through what IDOR is, how I exploited it on this app, the potential impact, and what developers can do to avoid this kind of security issue.

Before we dive into the juicy details, let’s cover the basics. IDOR, short for Insecure Direct Object Reference, is a type of access control vulnerability. It happens when an application uses user-supplied input to access objects (like database records, files, or resources) without proper authorization checks.

Fig:1 IDOR Explanation

In simpler terms, if a website uses something like https://example.com/user?id=123 to fetch user data, and it doesn’t verify if the requesting user actually has permission to access that data, it’s an IDOR vulnerability. This means anyone with basic knowledge could change the ID to someone else’s ID (e.g., id=124) and access another user’s information—sounds dangerous, right?

we will classify the severity of this issue here.

The severity of an IDOR depends on the impact. The vulnerability will have a higher severity where the attacker can use the IDOR to take over an important account, compared to the cases where access to unimportant information is found. Examples of severity with IDOR are:

Critical — Taking over an admin or all users account.High — Taking over another user’s account.Medium — Being able to view another user’s information.Low — Finding access to restricted data, though this can be higher depending on the kind and sensitivity of this data.Informational — Finding access to restricted, but unimportant, data.

I set up my proxy tool (I prefer Burp Suite, but you could use any similar tool like OWASP ZAP or Fiddler), and started inspecting the traffic between my browser and the server. While clicking on different user profiles, I noticed the following request https://example.com/api/users/12345

At this point, I had a gut feeling that this app might be vulnerable. So, I modified the 12345 endpoint to 67890, and bingo! I was able to view the profile details of a completely different user. The server wasn’t checking if I was authorized to view this user’s data—it was just fetching the information based on the ID I provided.

But wait, it gets worse. I wanted to see if I could go a step further. Could I modify another user’s data as well? Using Burp Suite, that would be shown next steps

After noticing that the user ID was being passed in the URL (/api/user/66a549a6c51d800011c25763), I decided to dive deeper to check if the application had proper access controls in place. Here’s how I approached the testing process:

Step 1: Setting Up the Proxy

First things first, I configured Burp Suite as my proxy tool to intercept the traffic between my browser and the application server

Step 2: Analyzing the HTTP Request

While exploring the application, I clicked on a user profile to view their details. Here’s the HTTP request that I intercepted using Burp Suite:

GET /api/user/66a549a6c51d800011c25763 HTTP/1.1
Host: redacted.com

As you can see, the request used the endpoint66309c53942eeb0012b99da0 to fetch the user details. This immediately raised a red flag because the user ID was exposed directly in the URL.

Step 3: Testing for IDOR — Accessing Another User’s Data

To verify if the application was vulnerable to IDOR, I modified the endpoint from 66a549a6c51d800011c25763to 666e743d046ff8001251aeda:

GET api/user/666e743d046ff8001251aeda HTTP/1.1
Host: redacted.com

I forwarded this modified request, and to my surprise, I received a response containing the profile details of another user! This confirmed that the application was not validating whether the requesting user had permission to access the data associated with the specified user ID.

Step 4: Going a Step Further — Modifying User Data

I wanted to see if this vulnerability was limited to viewing data or if it extended to modifying user data as well. So, I navigated to the profile update feature and intercepted the request while attempting to update my own profile information. Here’s the intercepted request:

PUT api/user/66a549a6c51d800011c25763 HTTP/1.1
Host: redacted.com
Content-Type: application/json
Cookie: sessionid=abcd1234

{
"name": "Attacker",
"email": "attacker@example.com",
"phone": "900000000"
}

The userId field was included in the request header. This was another potential vulnerability since the server should ideally determine the user ID based on the session token instead of allowing it to be set by the client.

I decided to test this by changing the userId value to 66309c53a4562abc2452c2, which was the ID of a different user:

PUT api/user/666e743d046ff8001251aeda HTTP/1.1
Host: redacted.com
Content-Type: application/json
Cookie: sessionid=abcd1234

{
"name": "Victim You are Hacked 😈",
"email": "attacker@example.com",
"phone": "900000000"
}

Step 5: Verifying the Exploit

After forwarding the modified request, I reloaded the profile page for user ID 1024. To my shock, the profile information had been successfully updated! The server had accepted my request without verifying if I had permission to modify the data for another user.

The application did not implement proper authorization checks. It trusted the endpoint value sent by the client without verifying it against the logged-in user’s session. This is a classic case of an IDOR vulnerability, which can have severe implications, especially when it allows unauthorized users to modify sensitive data.

Let’s talk about the potential impact here. If exploited by a malicious user, this vulnerability could lead to:

Data Manipulation: Attackers could modify sensitive user information, potentially leading to account takeovers.Privacy Violations: Personal information such as names, email addresses, and phone numbers could be exposed to unauthorized users.Business Reputation Damage: Data breaches caused by such vulnerabilities can harm a company’s reputation and may result in legal consequences, especially with data protection laws like the Indian IT Act or GDPR.

To prevent IDOR vulnerabilities, developers should:

Enforce Server-Side Authorization: Always verify the user’s permissions on the server side before allowing access or modifications to any sensitive data.Instead of relying on client-supplied data (userId), use the session or token information to determine the authenticated user’s ID.Use Indirect Object References: Avoid exposing internal identifiers like userId directly in URLs or request payloads. Use secure tokens or hashed references instead.Perform Regular Security Audits: Conduct frequent penetration tests and code reviews to identify and fix potential vulnerabilities before they can be exploited.

This experience was a great reminder of why we, as security researchers, should always trust our instincts when we see something odd. An IDOR vulnerability might seem like a simple bug, but its impact can be far-reaching, exposing user data and even allowing unauthorized data manipulation.

I hope this blog helped shed light on how IDOR vulnerabilities can be discovered and exploited, as well as what steps developers can take to mitigate them. If you enjoyed reading, don’t forget to give this post a clap and share it with your friends!

Sulman Farooq S is a passionate cybersecurity enthusiast with over three years of experience in penetration testing and specializes in network, web application, mobile application, and API penetration testing. Follow me on Medium for more insights into cybersecurity and vulnerability assessments.

Until next time, stay curious and keep hunting! 🕵️‍♂️🔍