Cross-Site Request Forgery (CSRF) is an attack where another website causes a logged-in user's browser to send a request to your app. Because the browser automatically attaches the session cookie, the forged request runs with the user's privileges. It works without stealing any credentials, using only a page the victim visits while signed in.
How the attack works
The user is logged into your app, which uses a cookie session. They visit a malicious page that contains a hidden form or request pointed at your app. The browser sends it along with the cookie, and your server, seeing a valid session, performs the action, for example changing an email or making a transfer.
How to prevent it
Two layers. Set sameSite on the session cookie so the browser will not send it on cross-site requests, and require an unguessable CSRF token on every state-changing request that the attacker's page cannot know. APIs authenticated with a bearer token in a header rather than a cookie are not vulnerable in the same way.
What this means for AI-generated code
CSRF is invisible in the path an AI tool builds: the form works and the update succeeds, so nothing signals the missing defense. Assistants ship cookie-based sessions without the token check because it is not needed for the feature to function.
Common questions
Do Next.js or React apps need CSRF protection?
It depends on how your API is authenticated. If your API uses a session cookie for authentication, you need CSRF protection — set sameSite=Lax or Strict on the cookie, and add a CSRF token for sensitive mutations. If your API uses a bearer token in an Authorization header, CSRF is not a concern because the attacker's page cannot read or set headers on cross-site requests.
What does sameSite on a cookie actually do?
It tells the browser not to send the cookie on cross-site requests. sameSite=Strict means the cookie is only sent on same-site navigations. sameSite=Lax allows it on top-level navigations (clicking a link) but not on embedded requests, which blocks most CSRF attacks. sameSite=None sends the cookie everywhere but requires Secure. Lax is the browser default for most modern browsers.
Is CSRF still relevant for modern SPAs?
Less so than for traditional server-rendered forms, because SPAs typically use bearer tokens in headers for API calls, not cookies — and cross-site requests cannot set custom headers. But if any part of your app authenticates with a session cookie (for example for SSR or a separate admin panel), CSRF is still a real risk for those endpoints.