Insecure Direct Object Reference (IDOR)
IDOR is an access control vulnerability where an application exposes internal object references (like database IDs) and fails to verify that the requesting user is authorized to access the referenced object.
Understanding Insecure Direct Object Reference (IDOR)
IDOR vulnerabilities arise when an application uses user-supplied input to directly access database records, files, or other resources without checking whether the user has permission. The classic example is a URL like /api/invoices/1234 that returns invoice 1234 to any authenticated user, regardless of whether that invoice belongs to them. By changing the ID to 1235, an attacker can access another user's invoice.
IDOR is a subset of broken access control, specifically focused on object-level authorization. It is particularly common in REST APIs where resources are accessed by ID. The vulnerability exists whenever the application trusts the user to only request their own resources rather than enforcing ownership server-side.
Sequential integer IDs make IDOR trivially exploitable — an attacker simply iterates through numbers. UUIDs make it harder to guess valid IDs but are not a security control on their own. Security through obscurity (using hard-to-guess IDs) merely raises the bar; proper authorization checks are the real defense.
Prevention requires checking ownership or permissions for every object access. For a user requesting /api/invoices/1234, the server must verify that invoice 1234 belongs to the authenticated user before returning it. This check must be enforced on every endpoint that accesses user-specific data: GET, PUT, PATCH, DELETE, and any action endpoints. Database-level controls like RLS can enforce this automatically.
Why This Matters for Vibe-Coded Apps
IDOR is arguably the most common vulnerability in vibe-coded APIs. When you ask an AI to build a REST API for a resource, it generates endpoints that fetch by ID without ownership checks. The AI creates a working API — authenticated users can access their own data — but it does not prevent them from accessing other users' data by changing the ID.
Every API endpoint in your vibe-coded app that accepts a resource ID should include an ownership check: verify the resource belongs to the authenticated user before returning it. In Supabase, RLS handles this if properly configured. In custom APIs, add a WHERE clause that includes both the resource ID and the authenticated user's ID.
Real-World Examples
AT&T iPad Email Leak (2010)
An IDOR vulnerability in AT&T's website exposed 114,000 iPad owners' email addresses. The API endpoint accepted an ICC-ID (SIM card identifier) and returned the associated email address without authentication. Researchers iterated through ICC-IDs to harvest the email addresses.
Facebook Photo Album Access (2015)
A researcher discovered that Facebook's Graph API returned private photo albums when accessed with their numeric ID, regardless of privacy settings. The IDOR allowed anyone to view any user's private photo albums by enumerating album IDs through the API.
Uber Driver Information IDOR (2019)
An IDOR in Uber's API allowed any authenticated user to retrieve any driver's personal information (name, photo, vehicle details, ratings) by changing the driver ID in API requests. The vulnerability exposed sensitive personal data of Uber's entire driver base.
Frequently Asked Questions
Do UUIDs prevent IDOR?
No. UUIDs make it harder to guess valid IDs through enumeration, but they do not prevent IDOR. If an attacker obtains a valid UUID (through another API response, logs, shared links, or Referer headers), they can still access the resource. UUIDs are security through obscurity — they slow down attackers but do not stop them. Always implement proper authorization checks regardless of ID format.
How do I test for IDOR?
Create two test accounts. As user A, perform actions and note the resource IDs in URLs, API responses, and request bodies. Then, as user B, attempt to access those same IDs. If user B can view, modify, or delete user A's resources, you have an IDOR. Test every endpoint that accepts an ID parameter, including GET, PUT, DELETE, and any action endpoints. Pay special attention to nested resources where the parent ID check may be enforced but the child resource ID is not.
Is IDOR the same as broken access control?
IDOR is a specific type of broken access control. Broken access control is the broad category covering any failure to enforce permissions — missing role checks, function-level access control, horizontal and vertical privilege escalation. IDOR specifically refers to the pattern where the application uses direct references to objects (database IDs, file paths) without verifying the requester's authorization to access those specific objects.
How does RLS prevent IDOR in Supabase?
RLS policies add automatic WHERE clauses to every database query. A policy like USING ((SELECT auth.uid()) = user_id) ensures that any SELECT query only returns rows where the user_id matches the authenticated user, regardless of what IDs are requested. This makes IDOR impossible at the database level — even if the API passes through an unauthorized ID, the database returns nothing because the row does not match the policy.
Is Your App Protected?
VAS automatically scans for vulnerabilities related to insecure direct object reference (idor) and provides detailed remediation guidance. Our scanner targets issues common in AI-generated applications.
Scans from $5, results in minutes. Get actionable fixes tailored to your stack.
Get Starter Scan