IDOR in Vibe Coded Apps

What is IDOR?

IDOR (Insecure Direct Object Reference) is when an application exposes internal references like database IDs and fails to verify that the requesting user has permission to access that specific resource.

Think of it like an apartment building where every door has a number but no locks. You live in apartment 203, but nothing stops you from opening door 456 and walking into someone else's home. The building knows who you are (authentication), but it does not check if you should access that specific apartment (authorization).

According to OWASP Top 10 (2021), Broken Access Control (which includes IDOR) ranks #1 in web application security risks. OWASP found that 94% of applications tested had some form of broken access control. IDOR vulnerabilities are frequently reported on HackerOne, often earning significant bounties due to their high impact. For vibe coders, IDOR is especially dangerous because AI tools typically add authentication but not per-resource authorization.

How do AI tools create IDOR vulnerabilities?

AI tools create IDOR vulnerabilities by implementing authentication (checking if someone is logged in) but skipping authorization (checking if they should access this specific resource).

// AI-generated endpoint - has auth but no authorization
export async function GET(
  request: Request,
  { params }: { params: { id: string } }
) {
  const session = await getServerSession(authOptions)

  if (!session) {
    return Response.json({ error: 'Unauthorized' }, { status: 401 })
  }

  // VULNERABLE: Returns ANY order, not just user's orders
  const order = await db.order.findUnique({
    where: { id: params.id }
  })

  return Response.json(order)
}

// User A calls: GET /api/orders/order-123 ✓ Gets their order
// User A calls: GET /api/orders/order-456 ✓ Gets User B's order!

Why this happens: When vibe coding and you ask for "an API to get order details," AI understands you need auth and adds it. But authorization requires understanding your data model, specifically which orders belong to which users. AI does not automatically infer this relationship from a simple prompt.

All major AI coding tools (Cursor, Claude Code, Bolt, v0, Windsurf, and GitHub Copilot) exhibit this pattern. The fix requires explicitly checking resource ownership in every endpoint.

What could happen if I have IDOR?

IDOR can result in complete data breach, privacy violations, data manipulation, and financial fraud.

• Mass data theft: Attackers enumerate IDs (123, 124, 125...) to download all user data, orders, messages, or documents
• Privacy violations: Access personal information, medical records, financial data, private messages of other users
• Data manipulation: Modify other users' profiles, change their settings, update their records
• Financial fraud: View other users' payment info, modify transactions, access invoices with sensitive data
• Account takeover: Access password reset tokens, session data, or account recovery information for other users

How do I detect IDOR?

Detect IDOR by reviewing every endpoint that takes an ID parameter and checking if it verifies the user owns or has permission to access that resource.

// Pattern 1: Direct database lookup with user-provided ID
const order = await db.order.findUnique({
  where: { id: params.id }  // No check that user owns this order
})

// Pattern 2: Auth check but no ownership check
if (!session) return unauthorized()
const document = await getDocument(params.documentId)  // Any user's document

// Pattern 3: Filtering by ID but not by user
const invoice = invoices.find(i => i.id === params.invoiceId)  // Not filtered by userId

// Testing checklist:
// 1. Find all routes with :id, [id], {id} parameters
// 2. For each, check: does it verify user owns/can access this ID?
// 3. Test: can User A access User B's resources by changing the ID?

// Manual test:
// 1. Login as User A, create an order, note the ID
// 2. Login as User B
// 3. Try to access User A's order ID - if it works, you have IDOR

How do I fix IDOR?

Fix IDOR by adding authorization checks that verify the authenticated user owns or has permission to access the requested resource. Always filter queries by user ID or check ownership before returning data.

// Has authentication, but no authorization
export async function GET(
  request: Request,
  { params }: { params: { id: string } }
) {
  const session = await getServerSession(authOptions)
  if (!session) {
    return Response.json({ error: 'Unauthorized' }, { status: 401 })
  }

  // IDOR: Returns ANY order, not just user's
  const order = await db.order.findUnique({
    where: { id: params.id }
  })

  return Response.json(order)
}

// Any logged-in user can view any order

// With authorization check
export async function GET(
  request: Request,
  { params }: { params: { id: string } }
) {
  const session = await getServerSession(authOptions)
  if (!session) {
    return Response.json({ error: 'Unauthorized' }, { status: 401 })
  }

  // SECURE: Only returns if user owns this order
  const order = await db.order.findUnique({
    where: {
      id: params.id,
      userId: session.user.id  // Ownership filter
    }
  })

  if (!order) {
    // Return 404, not 403, to not reveal existence
    return Response.json({ error: 'Not found' }, { status: 404 })
  }

  return Response.json(order)
}

Frequently asked questions

Related content