Next.js limits CSRF on Server Actions by allowing only POST and by comparing the Origin header to the Host header. If requests reach your app through a reverse proxy with a different host, set serverActions.allowedOrigins so legitimate requests are not rejected.
Why Server Actions raise CSRF questions
A Server Action can be invoked from a form element, which means a malicious page could try to submit a form to your site using the visitor's cookies. That is the textbook CSRF setup.
The two built-in defenses
According to the Next.js data security guide:
- POST only. Server Actions use the POST method, and only POST is allowed to invoke them. Combined with SameSite cookies being the default in modern browsers, the guide says this prevents most CSRF problems.
- Origin check. Next.js compares the Origin header with the Host header, or X-Forwarded-Host. If they do not match, the request is aborted. So an action can only be invoked from the same host as the page that hosts it.
The guide also points out that Next.js uses POST for mutations generally, which avoids accidental side effects from GET requests.
When you need allowedOrigins
If your app runs behind a reverse proxy or a multi-layered backend where the server's host differs from the production domain, the Origin and Host comparison can fail for real users. The guide recommends the serverActions.allowedOrigins option, which takes an array of strings.
module.exports = {
experimental: {
serverActions: {
allowedOrigins: ['my-proxy.com', '*.my-proxy.com'],
},
},
}
Keep the list as narrow as you can. A wildcard widens who may call your actions, so list only the proxy hostnames you control.
Do not mutate during render
The guide warns against triggering mutations as a side effect of rendering, for example logging a user out when a query parameter is present. Next.js blocks setting cookies and cache revalidation in render methods. Put mutations in actions.
What these defenses do not do
They address cross-site forgery. They do not decide whether the signed in user may perform the action. You still need authorization inside the action. See why Server Actions are public endpoints.
Quick check
Do I need allowedOrigins for a simple deployment?
Usually not. It matters when a proxy or layered backend makes the Host header differ from your production domain.
Does SameSite make CSRF checks unnecessary?
The docs treat it as one layer alongside POST only and the Origin check, not as a replacement.
Sources
Last reviewed: 19 October 2026.
