IDOR Vulnerability: What It Is and How to Prevent It
An IDOR vulnerability — short for Insecure Direct Object Reference — is one of the most common and damaging flaws in modern web applications, ranking under OWASP A01:2021 (Broken Access Control). It occurs when an application exposes internal object references (like database IDs, file paths, or account numbers) directly in URLs or request parameters without verifying that the requesting user is actually authorized to access that object.
Scan your site for IDOR-related misconfigurations with ZeriFlow — free, no sign-up needed.
What Exactly Is an IDOR Vulnerability?
At its core, IDOR is an authorization failure, not an authentication failure. A user is authenticated (they logged in), but the application never checks whether they're *allowed* to see the resource they're requesting.
Consider this URL:
GET /api/invoices/1042If the server returns invoice #1042 to any authenticated user — regardless of who owns that invoice — you have an IDOR vulnerability. An attacker simply increments the number to 1043, 1044, and so on, downloading every invoice in the system. This is sometimes called an 'IDOR attack' or 'horizontal privilege escalation'.
IDOR affects any resource type: user profiles, order histories, medical records, private files, admin endpoints, and more.
Sequential IDs vs. UUIDs — Why It Matters
One of the most common misconceptions is that switching from sequential integers (/user/1001) to UUIDs (/user/f47ac10b-58cc-4372-a567-0e02b2c3d479) fixes IDOR. It does not.
UUIDs reduce *discoverability* — an attacker can't guess the next ID. But if the application still doesn't check authorization, a UUID endpoint is still vulnerable. An attacker who obtains a UUID through a referral link, a shared URL, or another leak can still access the resource.
The real fix is server-side authorization, not obfuscation.
That said, UUIDs do meaningfully raise the bar for enumeration attacks, and should be used alongside proper access control — not instead of it.
Real-World IDOR Examples
1. The Horizontal IDOR
Alice is logged in and her user ID is 501. She requests:
GET /api/profile?user_id=501She changes the parameter to 502 and gets Bob's full profile, including his email and phone number. The server never checked that Alice is only allowed to see her own profile.
2. The Vertical IDOR
A standard user discovers that admin reports live at:
GET /reports/admin/monthly-revenueNo admin check is performed on the server. They access it directly and see sensitive business data.
3. The Indirect IDOR (File Path)
A document management system serves files like this:
GET /documents/download?file=contracts/client_501.pdfBy changing the filename, an attacker traverses to /contracts/client_502.pdf and downloads another client's contract. This is IDOR combined with path traversal.
How Attackers Find IDOR Vulnerabilities
Security researchers and malicious actors use similar techniques to discover IDOR flaws:
- Intercepting API traffic with tools like Burp Suite to observe object references in requests and responses
- Parameter tampering — changing IDs, GUIDs, filenames, or slugs to see if access control is enforced
- Mass assignment exploitation — sending unexpected fields in JSON bodies that the server processes without validation
- Fuzzing predictable patterns — incrementing, decrementing, or substituting values systematically
- Checking indirect references — references in HTTP headers, cookies, hidden form fields, and JSON Web Tokens
IDOR vulnerabilities are particularly dangerous because they require no special tools or exploits. A browser's developer tools are sufficient to find and exploit many of them.
IDOR Prevention: The Right Way to Build Access Control
1. Always Validate Authorization Server-Side
Every single request that accesses a resource must include a server-side check: 'Does the currently authenticated user own, or have explicit permission to access, this specific object?'
# BAD — no authorization check
def get_invoice(invoice_id):
return db.query('SELECT * FROM invoices WHERE id = ?', invoice_id)
# GOOD — ownership check enforced
def get_invoice(invoice_id, current_user):
invoice = db.query(
'SELECT * FROM invoices WHERE id = ? AND user_id = ?',
invoice_id, current_user.id
)
if not invoice:
raise ForbiddenError()
return invoice2. Use Indirect Object References
Instead of exposing raw database IDs, map them to user-specific tokens. A user sees /invoice/session-ref-7f3a which the server resolves to the actual database ID — after confirming the session belongs to the right user.
3. Implement Role-Based Access Control (RBAC)
Structure your authorization around roles and permissions. Middleware should enforce that a user has the required role before the controller even runs.
4. Test Every Endpoint
Automated testing should include cross-account access tests. Create two test users. Authenticate as User A, grab a resource ID, then attempt to access it as User B. Any successful response is a bug.
5. Audit Logs and Anomaly Detection
Monitor for access patterns that suggest enumeration: a single user requesting hundreds of different IDs in a short window is a red flag.
IDOR and the OWASP Top 10
IDOR falls under OWASP A01:2021 — Broken Access Control, which is now the single most prevalent vulnerability category in web applications. The OWASP testing guide dedicates an entire section (WSTG-ATHZ-04) to IDOR testing.
According to OWASP data, 94% of applications tested in their dataset had some form of broken access control. IDOR is a particularly impactful subtype because it scales: a single missing authorization check across a whole resource type exposes every record in that category.
Automated Scanning and ZeriFlow
While IDOR is fundamentally a logic flaw that requires manual review and business context to fully test, automated scanners play a critical role in identifying the structural conditions that make IDOR likely: missing security headers, predictable resource naming patterns, overly permissive CORS configurations, and verbose error messages that expose internal object structures.
ZeriFlow's 80+ checks cover the configuration layer — helping you catch the low-hanging fruit so your manual security review can focus on the logic layer.
FAQ
Q: What is the difference between IDOR and privilege escalation?
A: Privilege escalation is the broader concept of gaining more access than intended, either horizontally (accessing another user's data at the same privilege level) or vertically (gaining higher-privilege access). IDOR is a specific mechanism that enables horizontal privilege escalation by exposing direct references to objects without proper authorization checks.
Q: Does using UUIDs instead of sequential IDs prevent IDOR?
A: No. UUIDs make IDs harder to guess, which reduces the attack surface for enumeration, but if the server doesn't check ownership or permission, a UUID endpoint is still vulnerable. Proper server-side authorization is the only real fix.
Q: Can automated scanners fully detect IDOR vulnerabilities?
A: Automated scanners cannot fully detect IDOR because it's a logic flaw — the scanner doesn't know your business rules. However, scanners like ZeriFlow can identify related weaknesses (information exposure, permissive CORS, verbose errors) that make IDOR exploitation easier. Manual testing with two accounts remains essential.
Q: How do I test my own application for IDOR?
A: Create two separate accounts. Authenticate as Account A, perform actions and note all resource identifiers (IDs, GUIDs, filenames) in URLs and API responses. Then authenticate as Account B and attempt to access those same resources. Any successful access is an IDOR vulnerability.
Q: Is IDOR a critical vulnerability?
A: Yes. IDOR vulnerabilities can expose every record in a database to unauthorized access. In regulated industries (healthcare, finance), they can trigger GDPR, HIPAA, or PCI-DSS violations with significant financial and reputational consequences. Bug bounty programs routinely pay $500–$10,000+ for IDOR reports depending on data sensitivity.
Conclusion
IDOR vulnerabilities are deceptively simple — a missing check, a predictable ID, and an attacker has access to data that isn't theirs. The good news is that the fix is equally simple in concept: always validate authorization server-side, for every request, without exception.
Build a habit of asking 'who owns this resource, and did I check?' every time you write an endpoint that returns user-specific data. Pair that discipline with automated scanning to catch the configuration-level issues that create risk.