Insecure Direct Object Reference

How an IDOR Works

Imagine an API endpoint that returns an invoice at /api/invoices/1001. If the server checks that the user is logged in but not that invoice 1001 belongs to them, changing the number to 1002 returns another customer's invoice. The same pattern applies to updates and deletes, which can be even more damaging.

IDOR vs BOLA

In API security, the same flaw is usually called broken object level authorization (BOLA), and it ranks first in the OWASP API Security Top 10. In the main OWASP Top 10, it falls under broken access control, which is the top category in the 2025 edition. MITRE tracks the underlying weakness as CWE-639.

Why Scanners Miss IDOR

The vulnerable code usually looks normal. It reads an ID, queries the database and returns the result. Spotting the problem requires knowing the authorization model: which users own which objects and which roles can act on them. Pattern-matching tools rarely have that context, so IDOR is often found by manual testing or not at all.

How to Prevent IDOR

• Check authorization on every object access. Verify the user can act on the specific record, not just that they are logged in.
• Scope queries to the user. Look up records through the current user's account or tenant rather than by raw ID alone.
• Centralize access control. Use shared authorization logic instead of repeating checks in each handler.
• Test with multiple accounts. Try every sensitive request as a different user and a lower-privileged role.

Random or unguessable IDs make enumeration harder, but they are not a substitute for an authorization check.

How Nullify Finds IDOR

Nullify's code security analysis reasons about how the application works to catch IDOR, privilege escalation and other authorization failures that signature-based SAST misses, and the AI pentest agent tests REST and GraphQL APIs with multi-stage exploitation. See how Nullify Code Security catches authorization flaws.