high
Security Vulnerability

Insecure Direct Object Reference (IDOR)

IDOR occurs when applications use user-controllable identifiers to access objects without proper authorization checks, allowing access to other users' data.

Scan for This Vulnerability

What 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.

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.

Is Your App Vulnerable?

VAS automatically scans for insecure direct object reference (idor) and provides detailed remediation guidance.

Run Security Scan