Next.js Server Actions: Mutations & Security (Cheat Sheet)

You write a deleteComment(commentId) Server Action, wire it to a trash-can button, and it just works — no fetch, no /api route, no JSON.stringify. It feels like the network disappeared, like you called a local function from a click handler. Ship it, move on.

A week later someone opens their browser's dev tools, finds a POST request to your app with a long encrypted ID in the body, and replays it with a commentId that isn't theirs. It works. There was never a network boundary to disappear — you just couldn't see it. Every Server Action you write compiles into a real HTTP endpoint, and Next.js never assumed you'd add the authorization check yourself.

This article is written against Next.js 16.3 (verified against the framework's own release notes and npm's latest dist-tag in September 2026). Everything here — the 'use server' directive, useActionState, useOptimistic, and the built-in CSRF protections — is current App Router behavior, not a Pages Router pattern in disguise.

By the end of this article you'll be able to:

You've built at least a small App Router project — a page.tsx, maybe a form that posts to an API route. You don't need prior experience with Server Actions; we build the model from nothing.

Here's the naïve version of that deleteComment action — the one that looks completely reasonable in a code review:

Nothing here checks who is asking. The function trusts its caller the way a same-process function normally can — because on the page, it looks like one. But 'use server' doesn't keep this code on the server in some abstract sense; it publishes it as a callable endpoint the client can reach. Open the Network tab after clicking Delete and you'll see a POST to your app's own origin, carrying an encrypted reference to this exact function and its argument. Any client that can construct that same request — not just your button — can call it, with any commentId it likes.

The bug isn't that Server Actions are insecure. It's that the syntax hides the network call so well that it's easy to forget one exists, and skip the check you'd never skip in a hand-written API route.

The mental model: a Server Action is not code that "runs on the server instead of the client." It's an RPC (remote procedure call) — a function whose body runs on the server, but whose invocation is a real HTTP request from whatever calls it, same as fetch("/api/comments/123", { method: "DELETE" }) would be.

When you mark a function with 'use server', the Next.js compiler:

Calling deleteComment(comment.id) from a click handler, under the hood, sends a POST request carrying that ID and the arguments, and awaits the response. The syntax reads like a function call because React and Next.js serialize the request and deserialize the response for you — but the trust boundary is exactly where it would be for a REST endpoint. Nothing about who is asking crosses that boundary automatically. That's the one fact this whole article hangs off.

There are two ways to mark a function as a Server Action, and they mean different things.

Inline, inside a Server Component, 'use server' goes at the top of the function body:

This action closes over params.id from its surrounding scope — a real convenience, and one that matters later in the security section.

At the top of a separate file, 'use server' on line one marks every exported function in that file as a Server Action:

Key concept: a Client Component can never define an inline Server Action — it can only import one from a 'use server' file. If a component needs to call a mutation from an onClick, that mutation has to live in its own server-only module.

The idiomatic entry point is a <form>'s action prop, not a click handler:

.bind(null, comment.id) pre-supplies the argument so the form doesn't need a hidden input for it — the bound value travels inside the encrypted action payload, not as plain form data.

Key concept: because this is a real <form>, it works before React hydrates and even with JavaScript disabled — the browser submits it as a normal POST and Next.js handles the round trip. That's progressive enhancement you get for free, and it's a strong reason to prefer action={} over an onClick that calls the function directly.

A raw form submission doesn't give you a pending spinner or an error message. useActionState (a React 19 hook; it replaced the older useFormState) wraps an action and gives you both:

Key concept: the function you pass to useActionState receives the previous state as its first argument and the submitted FormData as its second, and whatever it returns becomes the new state on the next render. That's how a form gets validation feedback without a separate useState and a manual fetch.

A mutation that doesn't invalidate anything leaves stale data on screen. Two functions from next/cache handle this:

If the mutation should also navigate — say, after creating a post — call redirect() from next/navigation. It belongs at the end of the action, never inside a try block (see Edge cases).

Waiting for a round trip before showing a "liked" heart feels slow. useOptimistic lets you render the assumed result immediately, then reconcile once the action resolves:

Key concept: the optimistic value rolls back automatically only if the action throws. If your action instead catches its own error and returns a value, the optimistic state sticks around until the real props change — so a Server Action backing a useOptimistic update should let real failures propagate, not swallow them into a returned { error } object the way Stage 3's form does.

This is the part worth being precise about, because getting it wrong in either direction is expensive — either you re-invent protections that already exist, or you assume protections that don't.

Next.js secures the transport:

None of the above answers who is allowed to call this. That's Stage 7, and it's on you, exactly as it would be inside a Route Handler:

Treat every Server Action as if it were a POST handler a stranger could call directly with a tool like curl — because, protected transport aside, that's exactly what it is. Check the session, check ownership of whatever's being mutated, and validate the input shape (a schema library like Zod on the FormData fields is the idiomatic App Router pattern) before touching the database.

No. They cover form-driven mutations from your own app's UI well; a public API, a webhook receiver, or a non-browser client still wants a Route Handler with a stable URL.

useActionState is useFormState's React 19 successor — the same shape (previous state in, new state out, plus a pending flag), under a name that reflects it isn't limited to forms. useFormState still works in the interim but is deprecated in favor of it.

The transport is: CSRF origin checks, encrypted action IDs, and encrypted closures all happen automatically. Authorization is not — every action still needs its own auth and ownership checks, the same as any endpoint you'd hand-write.

Only if your code lets it. The CSRF origin check blocks requests whose Origin doesn't match your app's Host (or an explicitly configured allowed origin), so a script on another site can't trigger it. A request crafted directly against your own origin — from curl, from your own signed-in browser session — still reaches the function, which is exactly why Stage 7's checks matter.

Almost always because the action caught its own error and returned a value instead of throwing. useOptimistic reverts on a thrown error, not on a returned one — see Stage 5.

That deleteComment bug from the top of this article has a one-line fix: a session and ownership check before the db.comment.delete call. The syntax will never remind you it's missing — the request in your Network tab is the only thing that will.

What's one Server Action in your own codebase you'd want to re-check for an authorization gap after reading this? Drop it in the comments.

▶️ Open the interactive playground →

Runs right in your browser — poke at it and watch the concept react live.

Think it clicked? Take the 8-question quiz →

Instant feedback, a hint on every question, and an explanation for each answer — right or wrong.

🚀 Want more like this? Every guide, playground, and quiz lives on bestpractic.org — open it and sign up free so the next one finds you.

Thanks for reading! Let's stay connected: