Server actions in production: forms, validation and the security rules

What is a server action?

A server action is an async server-side function that the client can invoke directly, with Next.js handling the network call, serialisation and revalidation for you.

Mark a function with "use server" — either at the top of a module or inside an async function — and Next.js compiles a reference the browser can call. Passing it to a form's action attribute means the form submits natively without JavaScript, then upgrades to a fetch-based submission once hydrated.

// app/contact/actions.ts
"use server";
import { z } from "zod";

const Schema = z.object({
  email: z.string().email(),
  message: z.string().min(20).max(5000),
});

export async function submitEnquiry(_prev: State, formData: FormData): Promise<State> {
  const parsed = Schema.safeParse(Object.fromEntries(formData));
  if (!parsed.success) {
    return { ok: false, errors: parsed.error.flatten().fieldErrors };
  }
  await sendEnquiry(parsed.data);
  return { ok: true };
}

How do you handle validation and error states?

Return errors as data. Throwing inside an action surfaces the nearest error boundary, which is right for unexpected failures and wrong for 'this email address is invalid'. Model expected failures as a returned state object and render them next to the field.

"use client";
import { useActionState } from "react";

export function EnquiryForm() {
  const [state, action, pending] = useActionState(submitEnquiry, { ok: false });
  return (
    <form action={action}>
      <input name="email" type="email" required aria-describedby="email-error" />
      {state.errors?.email && <p id="email-error">{state.errors.email[0]}</p>}
      <button disabled={pending}>{pending ? "Sending…" : "Send"}</button>
    </form>
  );
}

What are the security rules for server actions?

Authenticate and authorise inside every action, validate all input, and rate limit anything a stranger can reach.

1. 1Check the session inside the action body. Hiding the button in the UI is not access control — the endpoint stays callable.
2. 2Re-check ownership on every mutation: does this user own the record whose id was submitted?
3. 3Parse input with a schema before touching it. FormData contents are attacker-controlled strings.
4. 4Rate limit by IP and by account for anything unauthenticated — contact forms, signups, password resets.
5. 5Never accept a price, role, or permission flag from the client. Look it up on the server.
6. 6Keep secrets in the action module and import server-only so it can never be pulled into a client bundle.

Next.js protects the transport with origin checks and encrypted action ids, which mitigates classic CSRF. It does not and cannot know whether the current user is allowed to delete invoice 4821. That is your code's job.

When should you still write an API route?

• Third parties need to call it — webhooks, mobile apps, partner integrations.
• You need fine-grained control over HTTP semantics: status codes, custom headers, streaming responses.
• The endpoint is called by something that is not your React app.
• You want a stable public contract that survives frontend refactors.

Server actions are an internal mutation mechanism for your own UI. Route handlers are your public API. Most production apps we build have both, and the boundary is obvious once you ask who the caller is.

How do actions interact with caching?

After a successful mutation, call revalidateTag or revalidatePath inside the action so the server caches drop the stale entry, and Next.js refreshes the current route's client cache for form-driven submissions. For actions invoked programmatically from a client component, follow up with router.refresh() to update what the user is looking at.

For optimistic UI, useOptimistic gives you an immediate local update that reconciles when the action resolves — worth it for high-frequency interactions like toggling a like, unnecessary for a contact form.