In a Next.js App Router app, a deleteInvoice Server Action is only reachable from a delete button that the page renders for admins. Explain why rendering the button conditionally is not an authorization control, and where the check has to live instead.

## The mental model: an action is an endpoint When you mark a module or a function with `'use server'`, Next.js does not merely "run this on the server." It creates a callable endpoint. At build time each action gets a stable generated id; the client reference you import is a thin stub that POSTs to the current route URL, carrying that id in a Next-specific request header (`Next-Action`, visible in DevTools) and the arguments in the request body. The server dispatches on the id and runs your function. That means the surface area of your app is not "the pages I linked" but "every action the build emitted." Nothing about the endpoint depends on which component rendered the button, whether that component rendered at all, or whether the user is looking at your UI. ## Why conditional rendering is not a control ```tsx {session.role === 'admin' && <DeleteButton invoiceId={id} />} ``` This decides what a cooperating browser draws. An attacker is not a cooperating browser. They can: - open DevTools on any page that *did* render the button, copy the request as cURL, and replay it with a different body; - read the action id out of the client bundle or a previous response and craft the POST by hand; - keep a stale tab from when they legitimately had the role, and fire it after the role was revoked. The general rule: **anything the client can observe, the client can forge.** Role flags, hidden fields, disabled attributes, and "the button is not on the page" are all client-side facts. ## Where the check belongs Inside the action body, before any effect: ```ts 'use server' import { cookies } from 'next/headers' export async function deleteInvoice(invoiceId: string) { const store = await cookies() // async in Next 15+ const session = await getSession(store) // your auth layer if (!session) throw new Error('Unauthenticated') if (session.role !== 'admin') throw new Error('Forbidden') await db.invoice.delete(invoiceId, { tenantId: session.tenantId }) } ``` Two distinct checks are doing different jobs. **Authentication** answers "who is calling?" and must be derived from server-held state — a session cookie your server can verify — never from an argument. **Authorization** answers "may that caller do this to this row?" and usually needs the record: an admin of tenant A must not delete tenant B's invoice, so the ownership predicate belongs in the query itself rather than in a separate read-then-write. ## Common wrong answers *"Middleware already protects that route."* A `middleware.ts` matcher runs before requests and is a reasonable coarse redirect for unauthenticated traffic, but it is an optimistic check on a path pattern. It does not know which action id is being dispatched, it usually cannot do a database lookup cheaply, and matcher patterns drift. Next's own guidance is to keep the authoritative check next to the data. *"The action isn't imported anywhere anymore."* Export is what makes it reachable, not import. Dead actions left exported in a `'use server'` module are live endpoints. *"It's typed, so bad input can't get through."* TypeScript annotations are erased. The request body is whatever the caller sent. ## Failure mode this prevents The realistic incident is not a sophisticated attack: it is a role change that never propagates. A user is demoted, their open tab still holds the rendered button, and the action still runs because the only gate was rendering. Because the check now lives in the body, the very next invocation re-reads the session and fails — the control is evaluated at call time, on the server, every time. ## Practical framing for an interview Say the phrase "the `'use server'` boundary is a trust boundary." Then give the three concrete consequences: the endpoint exists whether or not the UI does; identity comes from the session, not from arguments; and the check runs on every call, so revocation is immediate. Add that you keep the check in one shared data-access layer rather than copy-pasting it into forty action bodies, so a missing check becomes structurally hard rather than a review-time catch.