Next.js checks Origin for Server Actions. Move the same logic to a route handler and it stops.

The asymmetry follows from who owns the dispatch. A Server Action is invoked through machinery the framework wrote, so it knows the call is supposed to originate from its own pages and it knows the deployed host; it compares the two and refuses before your function body executes ^[1]. A route handler is your exported POST receiving a Request. Next.js handed you the raw object precisely because it cannot know whether the caller is your own frontend, a mobile app, an external webhook, or another website entirely ^[2][3]. What you lose in the move is not a weakened check. It is the absence of one.

That makes the ordinary refactor a security change with no artifact. Lift a mutation out of a `'use server'` file, drop it into `app/api/transfer/route.ts`, point a fetch at it, and the session lookup still runs, the 401 still fires, and nothing in the build output records that the origin comparison went away ^[2][4]. The author of the post notes this started as pushback on an earlier argument that Server Actions are public, directly callable endpoints: commenters replied that at least actions are not CSRF-exposed the way a form post is, and he agrees they are right ^[6]. The agreement is the problem. A property that holds for one calling convention gets remembered as a property of the framework.

The manual version is three statements: read the header, compare it to a configured URL, return 403 ^[5][9]. Cheap enough that nobody will argue about the cost, and mechanical enough that it will be missed in exactly the handlers written at speed. Note also what that sample does to the callers the flexibility was for. A request with no Origin header at all fails the strict comparison and gets the 403 ^[10], so the same four lines that close the CSRF hole also lock out the server-to-server webhook that justified using a route handler in the first place. Anyone copying the snippet into a shared middleware layer inherits that behaviour across every endpoint at once.

So the work is classification, not code. The author is explicit that a genuinely public GET returning non-sensitive data does not care where the request came from, and that anything mutating state on behalf of an authenticated user does ^[8]. Every handler has to be sorted into one of those buckets by hand, and re-sorted whenever its job changes, because the framework has no opinion to lend you.

One more boundary worth keeping straight, since the same post draws it. Origin checking answers where a request came from and nothing else ^[7]. An action that correctly rejects a cross-site forgery will still delete the wrong user's account if it trusts an ID the client sent instead of deriving identity from the session ^[7]. The origin check is the part a framework can do for you. The authorization check requires knowing your data model, which is why it is still yours.