A Next.js Server Action is invoked as updateProfile.bind(null, userId) and updates the row whose id equals that first argument. The action does verify that a session exists. What is still wrong, and how would you fix it?

## Where the two checks diverge ```ts 'use server' export async function updateProfile(userId: string, formData: FormData) { const session = await getSession() if (!session) throw new Error('Unauthenticated') // authentication await db.user.update(userId, { name: formData.get('name') }) // no authorization } ``` The guard answers "is anyone logged in?" The write answers "which row?" — and the answer comes from the request. Those two facts are never connected, so every authenticated user can update every profile by changing one value in the POST body. The vulnerability class is broken object-level authorization (IDOR): the identifier of the object is attacker-controlled and no check ties it to the caller. ## Why the bound argument feels trustworthy and isn't `action.bind(null, id)` is the documented way to pass extra arguments to a Server Action, and it reads like a server-side capture because it is written in server code. It is not. The bound value is serialized into the payload the client holds and comes back on invocation. Next encrypts values that an action closes over before sending them to the browser, so the user cannot *read* them — useful when the closure incidentally captures something sensitive — but confidentiality is not integrity of intent. The server still ends up acting on a value that made a round trip through an environment you do not control, and the same is true of hidden `<input>` fields, URL segments, and anything read from `searchParams`. The rule to state: **an identifier that arrives with the request is an assertion by the caller, not a fact.** ## Fix one — do not accept the identifier When the object is always "the caller's own," the id has no business being a parameter: ```ts 'use server' export async function updateProfile(formData: FormData) { const session = await requireSession() await db.user.update(session.userId, { name: parse(formData).name }) } ``` This is the strongest form because the dangerous parameter no longer exists. A future refactor cannot forget a check that has no place to live. Prefer it whenever it applies. ## Fix two — scope the query, don't precede it When the id legitimately varies, the tempting shape is a read-then-decide: ```ts const row = await db.doc.find(docId) if (row.ownerId !== session.userId) throw new Error('Forbidden') await db.doc.update(docId, patch) // two statements, two chances to drift ``` That works, but the check and the mutation are separable — someone adds a second write path, or a batch endpoint, and only one of them carries the guard. Folding the predicate into the statement is more durable: ```ts const updated = await db.doc.updateWhere( { id: docId, ownerId: session.userId }, patch, ) if (updated === 0) throw new Error('Forbidden') ``` Now "not yours" and "does not exist" are the same outcome, which also avoids leaking existence through differing error messages or timings. ## Roles are the same trap one level up The identical defect appears with role or tenant values: a hidden field carrying `tenantId`, a `role` key in the form body, an `isAdmin` flag bound into the action. Every one of them is caller-supplied. The permission-bearing attributes must be re-read from the server-side session or from the database on each call — never accepted from the payload, and never carried over from what the page rendered. ## Detecting it in review A useful heuristic when reading a `'use server'` module: for each parameter, ask "if the client sent a different value here, would the action still do something?" If yes for any identifier, there must be a predicate somewhere in that body tying it to the session. Actions with zero identifier parameters are the ones you can review at a glance, which is a good reason to keep the argument list minimal even when passing the id would be convenient. ## What to say when asked "Session-exists is authentication. The row is selected by a value the client sent, so this is object-level authorization missing. Either drop the parameter and take the id from the session, or push ownership into the where-clause of the write so it cannot be bypassed. And bound arguments are not server-side state just because they were written in server code — Next encrypts closed-over values, which keeps them private, but they still arrive from the client."