SecureStartKit
SecurityFeaturesPricingDocsBlogChangelog
Sign inBuy Now
Home/Glossary/IDOR
Vulnerability Patterns

IDOR(Insecure Direct Object Reference)

Also known as: Insecure Direct Object Reference

Definition

IDOR (Insecure Direct Object Reference) is a vulnerability class where an application uses a user-supplied identifier (such as a userId or recordId) to look up data without verifying the requester is authorized to access that specific object. IDOR is the most common Server Action bug in AI-generated Next.js code.

What is IDOR?

IDOR happens when a Server Action accepts an identifier from the request payload and uses it directly in a database query. The classic shape is updateProfile({ userId, ...fields }): the action trusts userId from the form and updates that row. An attacker submits the victim's userId and the action dutifully overwrites the victim's profile.

How do you prevent IDOR in Next.js Server Actions?

Derive identity from the validated session, never from the request payload. The canonical pattern is: const user = await getUser(), then .eq('id', user.id) in the query. The session cookie is the source of truth for "who is this user?" because it carries a signed JWT that cannot be forged.

Where does IDOR fit in OWASP Top 10?

A01 Broken Access Control. The 2025 edition is the eighth in a row where Broken Access Control sits at #1. IDOR is one of the canonical examples in the OWASP cheat sheet. The defense is structural: in Next.js, never accept user IDs from the request, always read them from getClaims() or getUser().

Learn more

  • Backend-only Data Access
  • OWASP Top 10 for Next.js + Supabase
  • IDOR: Missing Ownership Check

Related terms

  • Server ActionsServer Actions are Next.js functions marked with the 'use server' directive that run on the server and can be called from client components. Every Server Action is a public HTTP endpoint and must validate inputs with Zod, authorize identity from the session, and never trust user IDs from the request payload.
  • getClaimsgetClaims is the Supabase Auth method that locally validates a JWT against the cached public key from the project's JWKS endpoint and returns the parsed claims. It replaces getSession for authorization because getSession reads the cookie without re-validating the signature.
  • OWASP Top 10The OWASP Top 10 is the consensus list of the ten most critical web application security risks, updated by the Open Worldwide Application Security Project. The 2025 edition (current as of 2026) includes Broken Access Control as A01, Cryptographic Failures as A02, and a new A10 for Mishandling of Exceptional Conditions.
← Back to full glossary