V3ndta Cybersecurity

Insecure Direct Object Reference (IDOR) vulnerabilities are a prime example of how small oversights in access control can lead to major security breaches. IDOR vulnerabilities have constantly show on OWASPS top 10 web vulnerabilities and they are the perfect bug for novice bug bounty hunters to cut their teeth on. Lets take a more in depth dive into this vulnerability.

What Is an IDOR Vulnerability?

An IDOR vulnerability occurs when an application provides direct access to objects (like database entries, files, or resources) based on user-supplied input without proper authorization checks. In simple terms, if changing a value in a URL or request allows a user to access data they shouldn’t be able to, that’s an IDOR.

Example:

httpGET /invoices/12345

If 12345 is the invoice ID of another user and the app doesn’t verify ownership, an attacker could change it to 12346, 12347, etc., and access sensitive data.

Why Are IDORs Dangerous?

IDORs can lead to:

• Unauthorized data access – View or download another user’s files, invoices, medical records, etc.
• Data manipulation – Change or delete another user’s data (especially dangerous in APIs).
• Privilege escalation – If object references control permissions or roles.

Common Locations for IDORs

• RESTful APIs (GET /users/{id})
• Query strings (?file=report123.pdf)
• POST bodies ({ "user_id": 5 })
• Hidden form fields
• Mobile apps and single-page applications (SPAs)
• Embedded URLs in emails

How to Find IDOR Vulnerabilities

Here’s a structured approach to detecting IDORs:

1. Understand the Object Model

Map out how resources (like users, documents, or orders) are referenced. Look for IDs in:

• URL paths
• Query parameters
• Form fields
• Headers and cookies
• API requests

2. Test as a Low-Privilege User

Log in as a standard user and identify object IDs or references you have access to and set Burp to intercept. Then:

• Change IDs incrementally
• Use another user’s known ID
• Replay requests with modified tokens or cookies

Example test:

httpGET /account/5489

Try:

httpGET /account/5488

Observe the response—do you get a 403 Forbidden or a valid result?

3. Leverage Tools

• Burp Suite (Community or Pro): Use the Repeater and Intruder tools to automate ID fuzzing. There are plenty of plugins that can automate some of this as well.
• Autorize Plugin (Burp): Detect authorization bypasses by comparing authenticated and unauthenticated responses. This is a great one to use, especially for first time bug hunters.
• Postman: Useful for testing API endpoints with modified parameters.
• Custom scripts: Write Python or Bash scripts to iterate through object IDs and log responses.

4. Check for Vertical and Horizontal Privilege Escalation

• Horizontal: Accessing another user’s data at the same privilege level.
• Vertical: Accessing admin-only resources or features. Use upwards escalation to leverage an IDOR into more lucrative bounties.

Preventing IDORs

For developers, prevention is more effective than patching:

• Enforce access controls server-side. Never trust the client.
• Use indirect object references like UUIDs or hashes instead of sequential integers.
• Implement role- and ownership-based checks on every resource-accessing function.
• Centralize authorization logic for consistency.

Real-World Example: Facebook’s Private Photos

In 2015, a researcher discovered that modifying a URL with a different photo ID allowed him to access private images on Facebook. This IDOR vulnerability earned him a bug bounty and highlighted how even tech giants can fall victim to poor access control.

Conclusion

IDORs may seem simple, but they are dangerously effective—often lurking in plain sight. With the rise of API-heavy architectures, they’re becoming more prevalent. For defenders, building in strong access control mechanisms is essential. For offensive security professionals, mastering the art of spotting IDORs can yield valuable findings and major impact.