IDOR (Insecure Direct Object Reference) is a type of vulnerability where an API fails to properly check whether the user requesting a resource is authorized to access it. In simpler terms, it lets an attacker access data they shouldn't be able to see by changing an object identifier (like a user ID) in the request.

In modern APIs, this is basically the same as what is called BOLA (Broken Object Level Authorization) except in today's API-driven systems, it's far more common and impactful because APIs expose so many objects directly.

When I started testing vAPI, I wanted to put myself in the attacker's shoes. The goal was simple: see how far I could go by manipulating API requests. I created a test account using the registration endpoint with this payload:

{
  "username": "agent1",
  "password": "agent",
  "name": "pen",
  "address": "space",
  "mobileno": "765468432"
}

Once the account was created, I explored the user endpoint /vapi/api5/user. Out of curiosity, I added an "s" to make /users, and without logging in, it returned all users in the system, including the admin account with a flag and its sensitive data:

{
    "id": 1,
    "username":"admin",
    "password":"Admin User",
    "name":"pen",
    "address":"flag{api5_76dd9900a97ff1563ae76}",
    "mobileno":"8080808080"
}

How the Vulnerability Occurs

IDOR occurs because the API does not enforce authorization at the object level. Any user can access objects (here, user accounts) that don't belong to them simply by changing the ID or endpoint path.

What a Tester Looks For

1. Create a test account.
2. Access endpoints that return user-specific or sensitive data.
3. Modify object identifiers (IDs, paths, or parameters).
4. Observe whether the API returns unauthorized data.

Potential Impact

• Exposure of sensitive information (personal info, flags, API keys).
• Unauthorized access to admin or privileged accounts.
• Potential account takeover or data breaches.

Attacker Mindset

Attackers look for simple manipulations. Changing IDs or parameters in requests can reveal information that wasn't meant to be public. APIs are particularly vulnerable because they are data-focused and often expose numerous objects directly.

Why APIs Are Vulnerable

• APIs often trust the client request and assume correct usage.
• Developers may forget object-level access checks.
• Sensitive fields are sometimes exposed unnecessarily.

How Developers Can Prevent It

• Always check object-level permissions.
• Use role-based or attribute-based access control
• Avoid exposing sensitive fields in responses unless required.
• Test APIs regularly for IDOR/BOLA vulnerabilities.

In conclusion, this lab demonstrates how a single oversight in API access control in this case, failing to enforce object-level authorization can expose sensitive data to anyone, even without logging in.

It highlights why IDOR/BOLA vulnerabilities are critical to identify and fix, and why developers must always enforce proper authentication and authorization at every endpoint to protect user data.