Next.js Server Actions security — the bugs everyone ships and the fixes

What it is

Server Actions are async functions marked with `"use server"` (either at the top of a file or inline). When a client component calls one, Next.js packages the call as a POST to a serialized endpoint. The function body runs on the server. Critically: the serialized endpoint is exposed and callable by anyone with the URL — there is no implicit auth boundary.

Vulnerable example

// app/actions/orders.ts
"use server";
import { db } from "@/lib/db";

// Bug: takes user_id from FormData and trusts it. Anyone who calls
// this Server Action with someone else's user_id reads their order.
export async function getOrder(formData: FormData) {
  const userId = formData.get("userId") as string;
  const orderId = formData.get("orderId") as string;
  return await db.from("orders")
    .select("*")
    .eq("id", orderId)
    .eq("user_id", userId)  // <-- attacker controls this
    .single();
}

Fixed example

// app/actions/orders.ts
"use server";
import { db } from "@/lib/db";
import { getAuthenticatedUser } from "@/lib/auth";

export async function getOrder(formData: FormData) {
  // 1. Resolve the user from the verified session — never from FormData.
  const user = await getAuthenticatedUser();
  if (!user) {
    throw new Error("unauthorized");
  }

  const orderId = formData.get("orderId") as string;

  // 2. Filter by the AUTHENTICATED user, not by client-supplied user_id.
  const { data: order } = await db.from("orders")
    .select("*")
    .eq("id", orderId)
    .eq("user_id", user.id)
    .single();

  // 3. If RLS is on the table (it should be), the .eq("user_id", ...)
  //    filter is redundant defense-in-depth. Either alone is a bug;
  //    both together is correct.
  if (!order) {
    throw new Error("not found");  // 404 shape — don't reveal existence
  }
  return order;
}

How Securie catches it

// app/actions/orders.ts
"use server";
import { db } from "@/lib/db";
import { getAuthenticatedUser } from "@/lib/auth";

export async function getOrder(formData: FormData) {
  // 1. Resolve the user from the verified session — never from FormData.
  const user = await getAuthenticatedUser();
  if (!user) {
    throw new Error("unauthorized");
  }

  const orderId = formData.get("orderId") as string;

  // 2. Filter by the AUTHENTICATED user, not by client-supplied user_id.
  const { data: order } = await db.from("orders")
    .select("*")
    .eq("id", orderId)
    .eq("user_id", user.id)
    .single();

  // 3. If RLS is on the table (it should be), the .eq("user_id", ...)
  //    filter is redundant defense-in-depth. Either alone is a bug;
  //    both together is correct.
  if (!order) {
    throw new Error("not found");  // 404 shape — don't reveal existence
  }
  return order;
}

Checklist

• Every Server Action calls `getAuthenticatedUser()` (or equivalent) FIRST, before any database read or write.
• Server Actions never read `user_id` from FormData / arguments — always from the verified session.
• Database queries filter by the authenticated user's ID, not by client-supplied identifiers.
• RLS is enabled on every Supabase table the Server Actions touch (defense in depth).
• Errors return generic messages (`'not found'`) — never reveal whether a resource exists.
• Sensitive Server Actions (admin, billing, account-deletion) check role beyond auth presence.
• Rate limiting on Server Actions that interact with external APIs or send emails.

FAQ

Related guides