Insecure Direct Object Reference (IDOR)
Last updated: January 12, 2026
IDOR occurs when applications use user-controllable identifiers to access objects without proper authorization checks, allowing access to other users' data.
Scan for This VulnerabilityWhat is Insecure Direct Object Reference (IDOR)?
When an application uses a user-supplied ID (like in /api/documents/123) without verifying the requesting user is authorized to access that specific resource, attackers can iterate through IDs to access other users' data. This is one of the most common authorization flaws.
Why It's Dangerous
This vulnerability can allow attackers to access sensitive data, compromise user accounts, or gain unauthorized control over your application. In AI-generated code, this issue is particularly common because security measures are often deprioritized in favor of rapid feature development.
Why AI Code Is Vulnerable
AI code generation tools focus on producing functional code quickly. They often generate patterns that work correctly but lack the defensive measures experienced security engineers would implement. This makes insecure direct object reference (idor) particularly prevalent in vibe-coded applications.
Understanding the Technical Details
Insecure Direct Object Reference (IDOR) is classified as a high-severity vulnerability because of its potential to cause significant damage to your application and users. Understanding the technical mechanics helps you recognize and prevent this issue in your own code.
This vulnerability typically occurs when security controls are either missing entirely, improperly configured, or incorrectly implemented. In many cases, the code appears to work correctly during development and testing, but the security flaw becomes exploitable once the application is deployed and accessible to malicious actors.
Attackers actively scan for this type of vulnerability using automated tools. Once discovered, exploitation can be rapid—often within hours of your application going live. The consequences range from data theft and account takeover to complete system compromise depending on the application's architecture.
For vibe-coded applications built with platforms like Lovable, Bolt.new, Replit, or v0.dev, this vulnerability appears in roughly 20-40% of deployments according to security research. The AI-generated patterns often follow insecure defaults that require manual security hardening.
How It Happens
- Missing ownership validation
- Only checking authentication, not authorization
- Sequential or predictable IDs
- Trusting user-supplied identifiers
Impact
Access to other users' private data
Modification of others' resources
Privacy violations
Data theft at scale
How to Detect
- Change IDs in URLs and see if other users' data loads
- Modify IDs in API requests
- Test with multiple user accounts
- Run VAS to test for IDOR
How to Fix
Verify resource ownership
Always check if the requesting user owns or can access the resource.
// Supabase RLS handles this automatically
CREATE POLICY "Users access own docs" ON documents
FOR ALL TO authenticated
USING ((select auth.uid()) = user_id);Add authorization checks in API
Explicitly verify authorization on every request.
// API route
const doc = await db.document.findFirst({
where: {
id: documentId,
userId: currentUser.id // Authorization check
}
});
if (!doc) {
return res.status(404).json({ error: 'Not found' });
}Use RLS for database queries
Let the database enforce authorization.
Commonly Affected Platforms
Prevention Best Practices
The most effective approach to insecure direct object reference (idor) is prevention. Implementing security measures during development is significantly easier and less costly than remediating vulnerabilities after deployment.
Security-First Development
When using AI code generation tools, always review the generated code for security implications. AI tools prioritize functionality over security, so treat all generated code as requiring security review. Establish a checklist of security requirements specific to your application type and verify each before deployment.
Continuous Security Testing
Integrate security scanning into your development workflow. Run scans after major code changes, before deployments, and on a regular schedule for production applications. Early detection of vulnerabilities reduces remediation costs and prevents potential breaches.
Defense in Depth
Never rely on a single security control. Implement multiple layers of protection so that if one control fails, others still protect your application. For example, combine authentication, authorization, input validation, and output encoding to create comprehensive protection against attacks.
Stay Informed
Security threats evolve constantly. Follow security researchers, subscribe to vulnerability databases, and monitor your dependencies for known issues. Understanding emerging threats helps you proactively protect your applications before attackers exploit new techniques.
Is Your App Vulnerable?
VAS automatically scans for insecure direct object reference (idor) and provides detailed remediation guidance with code examples. Our scanner specifically targets vulnerabilities common in AI-generated applications.
Scans from $5, results in minutes. Get actionable results with step-by-step fix instructions tailored to your stack.
Get Starter ScanFrequently Asked Questions
How do I test for IDOR vulnerabilities?
Create two test accounts. As User A, copy a resource URL (like /api/documents/123). Log in as User B and try to access that URL. If User B can see User A's document, you have IDOR. Test all endpoints: viewing, editing, deleting. Automate with tools like Burp Suite's Autorize extension.
Are UUIDs enough to prevent IDOR?
UUIDs make guessing harder (36 characters vs sequential numbers) but don't prevent IDOR. If an attacker obtains a UUID through another vulnerability (logs, referrer headers, error messages), they can still access the resource. Always combine UUIDs with proper authorization checks.
How does RLS prevent IDOR?
RLS policies check ownership at the database level. When you query SELECT * FROM documents WHERE id = $1, RLS automatically adds AND user_id = auth.uid(). Even if attackers try different IDs, they only get results matching their user_id. This is why RLS is the best defense for Supabase apps.
What's horizontal vs vertical privilege escalation?
Horizontal: accessing another user's resources at the same privilege level (user A reads user B's profile). Vertical: accessing higher-privilege resources (regular user accessing admin panel). IDOR is typically horizontal. Both require proper authorization checks - authentication alone doesn't prevent either.