DEV Community

Cover image for IDOR: What Is It and How Does One URL Change Expose Every User's Data?
Jer Catallo
Jer Catallo

Posted on

IDOR: What Is It and How Does One URL Change Expose Every User's Data?

#cybersecurity #tutorial #todayilearned #security

What Is IDOR and How Does One URL Change Expose Every User's Data?

IDOR, or Insecure Direct Object Reference, is one of the most common and easy-to-miss access control flaws in web applications. It happens when a server uses a value from the user, like a number in the URL, to fetch records without checking if that user is allowed to see them. No special tools needed, just a number change in the address bar.

Brief Introduction

When your profile loads at a URL like this:

http://<target>/profile?user_id=51
Enter fullscreen mode Exit fullscreen mode

The server takes that user_id value and returns the matching record. The problem starts when the server skips the ownership check: it does not verify if the logged-in user actually owns record 51. If you change it to 1, and the server returns someone else's profile, that is an IDOR.

The impact goes beyond just viewing data. Depending on the endpoint, an attacker could also edit or delete records that do not belong to them.

Ethical Considerations

The techniques shown here are for authorized testing only. Running these tests against systems you do not own or have written permission to test is illegal in most countries and violates computer fraud laws. Always get proper authorization before testing, work within a defined scope, and handle any discovered data with care. Use lab environments like TryHackMe or HackTheBox to practice safely.

Step 1: Identify the Target Endpoint

After logging in, the profile page loads user data based on an ID parameter in the URL. This is the starting point for testing access control.

The page shows the current user's information. The next step is to check whether the server validates ownership before returning data.

Step 2: Test for IDOR by Modifying the User ID

To test for IDOR, change the user_id value in the URL to sequential numbers. If the server returns data for other users without any authorization check, the vulnerability is confirmed.

GET /profile?user_id=51  # Original user
GET /profile?user_id=1     # Modified to another user's ID
Enter fullscreen mode Exit fullscreen mode

There is no server-side ownership check in place. The application returns the record for whatever ID is passed in.

Step 3: Access Other Users' Data

Changing the user_id to different values returns different users' profiles, each with their full details.

Each request returns a full profile belonging to a different user. No error, no redirect, no access denied, just the data. This confirms the server is serving records based on the ID value alone, with no check on who is asking.

Remediation

To fix this type of vulnerability:

  • Add server-side ownership checks: verify the requesting user matches the record owner before returning data
  • Use indirect references, such as mapping tables, so internal IDs are never exposed directly in requests
  • Apply the principle of least privilege across all endpoints
  • Include access control testing in code reviews and security assessments

A simple server-side check looks like this (example/simulation):

# Example: server-side ownership check
if current_user.id != requested_user_id:
    return 403  # Forbidden
Enter fullscreen mode Exit fullscreen mode

This single check would block the entire attack shown above.

Summary

IDOR is a straightforward flaw with a serious impact. By changing one number in a URL, you can access data that belongs to any other user in the system. The root cause is always the same: the server trusts user input and skips the ownership check. Fixing it requires access control validation on every endpoint that serves user-specific data. Understanding how IDOR works, including its encoded and hashed variants, gives you the foundation to find and fix it during security reviews.

If you found this helpful, drop a like and share it with someone learning security. If you have questions, ran into something different in your own lab, or want to share your results, leave a comment below. Always happy to connect and talk about security, recon techniques, or anything AppSec related.

Feel free to connect with me on LinkedIn

Always open to connecting with people in security, development, or both. Whether you are building something, breaking something, or just getting started, feel free to reach out.

Top comments (0)