Insecure Direct Object Reference (IDOR) — what it is and how to prevent it

What it is

An Insecure Direct Object Reference occurs when an application exposes a reference to an internal object (a database row, a file path, a tenant identifier) and relies on obscurity or client-side controls to prevent unauthorized access. When the reference is sent over the wire and the server does not re-authorize the access, the reference can be substituted by an attacker.

Vulnerable example

// Vulnerable: uses client-supplied user_id
export async function GET(req: Request) {
  const url = new URL(req.url);
  const userId = url.searchParams.get("user_id"); // <-- attacker-controlled
  const user = await db.user.findUnique({ where: { id: userId! } });
  return Response.json(user);
}

Fixed example

// Fixed: use session-derived identity, ignore client-supplied IDs for "me" endpoints
import { auth } from "@/lib/auth";

export async function GET() {
  const session = await auth();
  if (!session?.user?.id) return new Response(null, { status: 401 });
  const user = await db.user.findUnique({ where: { id: session.user.id } });
  return Response.json(user);
}

How Securie catches it

// Fixed: use session-derived identity, ignore client-supplied IDs for "me" endpoints
import { auth } from "@/lib/auth";

export async function GET() {
  const session = await auth();
  if (!session?.user?.id) return new Response(null, { status: 401 });
  const user = await db.user.findUnique({ where: { id: session.user.id } });
  return Response.json(user);
}

Checklist

• Never trust client-supplied IDs as the sole basis for authorization
• Prefer session-derived identity for 'me' endpoints (`/api/me/orders`, not `/api/orders?user=X`)
• Pair API-layer authz with database RLS — defense in depth
• Normalize error responses — do not leak existence through 404 vs 403 differences
• Audit-log every access to sensitive objects

FAQ

Related guides