• Agents
  • Docs
  • Pricing
  • Blog
Log in
Get started

Security for apps built with AI. Paste a URL, get a report, fix what matters.

Product

  • How it works
  • What we find
  • Pricing
  • Agents
  • MCP Server
  • CLI
  • GitHub Action

Resources

  • Blog
  • Docs
  • FAQ
  • Glossary

Security

  • Supabase Security
  • Next.js Security
  • Lovable Security
  • Cursor Security
  • Bolt Security

Legal

  • Privacy Policy
  • Terms of Service
  • Cookie Policy
  • Imprint
© 2026 Flowpatrol. All rights reserved.
Home/Glossary/IDOR
CWE-639CWE-284OWASP #1

Insecure Direct Object Reference (IDOR)

IDOR is a broken access control flaw where an application uses user-supplied input to directly reference an internal object — like a database row, a file, or an API record — without checking whether the requesting user is authorized to access it. It is classified under CWE-639 (Authorization Bypass Through User-Controlled Key) and falls within OWASP Top 10 #1: Broken Access Control.

What is IDOR?

Imagine you're logged into an app and viewing your profile at /api/users/42. You change the 42 to 43 and suddenly you can see someone else's data. That's IDOR.

The application trusts the ID in the request without verifying that you own it. The server fetches the row, the file, or the resource — and hands it over to whoever asks.

IDOR is technically a subset of Broken Access Control (CWE-284), but it's so common that it has its own classification: CWE-639. In the OWASP Top 10, Broken Access Control has been the #1 web application vulnerability category since 2021.

How does IDOR work?

An IDOR bug requires two things: a reference to an internal object that the user can control (usually an ID in a URL, query parameter, or request body), and a missing authorization check on the server side.

Here's a typical vulnerable API route in a Next.js app:

Vulnerable — no authorization check
// app/api/invoices/[id]/route.ts
export async function GET(req, { params }) {
  const invoice = await db.invoice.findUnique({
    where: { id: params.id },
  });

  // Problem: no check that this invoice belongs
  // to the requesting user.
  return Response.json(invoice);
}
Fixed — ownership verified
// app/api/invoices/[id]/route.ts
export async function GET(req, { params }) {
  const session = await getSession(req);

  const invoice = await db.invoice.findUnique({
    where: {
      id: params.id,
      userId: session.user.id, // ownership check
    },
  });

  if (!invoice) {
    return Response.json({ error: "Not found" }, { status: 404 });
  }

  return Response.json(invoice);
}

Why do AI tools generate IDOR vulnerabilities?

AI code generators are optimized for getting things working. When you ask for a CRUD API, the model generates routes that create, read, update, and delete records — and those routes work perfectly for a single user. The problem is that they rarely add per-user authorization.

  • Prompts focus on features, not security. "Build an invoice API" doesn't mention access control. The model delivers exactly what was asked for.
  • Training data includes vulnerable patterns. Many tutorials and Stack Overflow answers skip authorization checks for brevity. The model learned from them.
  • Authorization is context-dependent. The model can't know your app's ownership rules unless you tell it. It doesn't know that invoices belong to specific users.

According to Veracode's 2025 research, 45% of AI-generated code contains security flaws. IDOR is one of the most common categories because it requires understanding the relationship between users and data — something code generators consistently miss.

Common IDOR patterns

Sequential IDs in URLs

/api/orders/1001, /api/orders/1002 — easy to enumerate.

Body parameter manipulation

Changing { "userId": 42 } to { "userId": 43 } in a POST request.

File path references

/uploads/user-42/receipt.pdf — change the folder name.

GraphQL node queries

query { node(id: "base64-encoded-id") { ... } } with no auth.

How Flowpatrol detects IDOR

Flowpatrol doesn't just check for headers or run a CVE database lookup. It actually tests your app's access control the way a real attacker would:

  1. 1Creates multiple test users and logs in with separate sessions.
  2. 2Discovers data endpoints by crawling the app and observing API calls.
  3. 3Cross-tests access — tries to read User A's data using User B's session.
  4. 4Reports the finding with the exact request, the leaked data, and a copy-paste fix.

This is the kind of testing that traditional scanners skip entirely. They check for known CVEs. Flowpatrol checks your app's actual business logic.

Related terms

Broken Object Level Authorization (BOLA)RLS in Supabase & PostgreSQL (Row Level Security)Missing Admin Checks (Broken Function Level Authorization)

Check your app for IDOR.

Flowpatrol tests your access controls with real multi-user sessions. Five minutes. One URL.

Try it free