No Insecure Direct Object References (IDOR)

IDOR (Insecure Direct Object Reference) — CWE-639, CAPEC-143 — is one of the most reliably exploitable authorization failures: an attacker supplies someone else's resource ID and receives that resource. OWASP A01 (Broken Access Control) names IDOR as a primary example. The threat model is simple: authenticated user A calls GET /api/invoices/invoice-uuid-owned-by-user-B and receives user B's invoice. UUIDs reduce guessability but are not authorization controls — they merely slow brute-force enumeration. NIST 800-53 AC-3 requires access enforcement based on identity, not identifier obscurity. A single IDOR-vulnerable endpoint exposes every record in the affected table to any authenticated caller.

The fix is identical to resource ownership verification: include the user's ID in every query that fetches by a client-supplied ID. This applies whether the ID is in the URL path, a query parameter, or the request body.

// Pattern for every route with [id]:
const resource = await db.invoice.findFirst({
  where: { id: params.id, userId: session.user.id }
});
if (!resource) return NextResponse.json({ error: 'Not found' }, { status: 404 });

For cross-resource access (user has access through their organization), verify via the organizational membership table — db.orgMember.findFirst({ where: { orgId: resource.orgId, userId: session.user.id } }) — rather than checking direct ownership.