What are the security considerations for Server Actions in Next.js?

Q: What are the security considerations for Server Actions in Next.js?

**Target Audience:** Frontend engineers preparing for Next.js interviews — assumes basic React and App Router familiarity. **Difficulty:** Hard > **How to read this doc:** Each idea is explained in plain language first, then tagged with `📌 Interview term:`. Every behaviour claim was checked against the Next.js docs shipped with the package (written on 16.3.4, re-reviewed against 16.4.2) and, in the **Verified** section, against real output from a build or a running server; each Verified block says which version it ran on. ## 1. Why This Even Matters — A Story First A Server Action is a door with a keypad on the side of a building. The fact that the lobby has no sign pointing to it does not make it private; anyone walking along the street can try the keypad. Next.js fits a good lock (origin checks, encrypted ids), but deciding who may enter is still the job of the guard inside, which is your code. ## 2. The Core Idea 📌 **Interview term: CSRF** — cross-site request forgery: a mali

The problem

Question presented to candidate: "Your team moved all mutations to Server Actions. What are the security risks, which ones does Next.js handle for you, and what must every action still do?"

What a strong answer should cover:

Every exported action is a public HTTP endpoint: its id is in client code, and anyone can call it with a POST.
So every action must authenticate and authorise the caller itself; hiding the button is not access control.
Arguments and FormData come from the network: validate types and ranges on the server.
Next.js adds protections: POST only, an Origin versus Host check against CSRF, encrypted non-deterministic ids, removal of unused actions from the client bundle, encrypted closure variables, a 1 MB default body limit.
Keep return values minimal, because they are sent to the browser, and keep secrets out of action closures anyway.

Clarifying questions expected:

"Where is authentication checked today: in the page or in the action?" — it must be in the action.
"Is the app behind a reverse proxy?" — the Origin check may need experimental.serverActions.allowedOrigins.

Code / implementation expected: Yes — an action with authentication, authorisation and validation.

nextjs
server-actions
security
validation

Try it yourself

Sketch your approach before you read the solution. That is what the interview tests.

Stuck? Get a hint.

A short nudge toward the approach. It will not give the answer away.

Solution

Target Audience: Frontend engineers preparing for Next.js interviews — assumes basic React and App Router familiarity. Difficulty: Hard

How to read this doc: Each idea is explained in plain language first, then tagged with 📌 Interview term:. Every behaviour claim was checked against the Next.js docs shipped with the package (written on 16.3.4, re-reviewed against 16.4.2) and, in the Verified section, against real output from a build or a running server; each Verified block says which version it ran on.

1. Why This Even Matters — A Story First

A Server Action is a door with a keypad on the side of a building. The fact that the lobby has no sign pointing to it does not make it private; anyone walking along the street can try the keypad. Next.js fits a good lock (origin checks, encrypted ids), but deciding who may enter is still the job of the guard inside, which

The solution is hidden so you can try first

6 min read · 8 sections

Read the code

An action that checks identity, ownership and input

// app/posts/actions.ts
"use server";
import { z } from "zod";
import { revalidateTag } from "next/cache";
import { requireUser } from "@/lib/dal";    // throws if there is no valid session

const Input = z.object({ id: z.string().uuid() });

export async function deletePost(raw: unknown) {
  const user = await requireUser();                       // authentication
  const { id } = Input.parse(raw);                         // validation
  const post = await db.post.findUnique({ where: { id } });
  if (!post || post.authorId !== user.id) {               // authorisation
    return { ok: false as const, error: "Not allowed" };
  }
  await db.post.delete({ where: { id } });
  revalidateTag("posts", "max");
  return { ok: true as const };                             // minimal return value
}

Discussion

Other approaches, follow-ups and how it went in real interviews.

Sign in to join the discussion.

No comments yet. Share how you would answer it.

The solution is hidden so you can try first

Keep your momentum going.