CSRF Protection in React and API Setups

Cross-Site Request Forgery (CSRF) is an attack where a malicious website tricks the user's browser into sending an authenticated request to your API. Because the browser automatically attaches cookies to requests, the server cannot distinguish between a legitimate request from your app and a forged request from the attacker's site.

Cookies are the root cause of CSRF vulnerability. When a user is logged into your app, their session cookie is stored in the browser. When they visit the attacker's page, the attacker can trigger a form submission or fetch request to your API, and the browser automatically includes the session cookie — authenticating the malicious request.

The SameSite cookie attribute tells browsers when to include cookies in cross-site requests. It has three values: Lax (the default in modern browsers — blocks cross-site POST but allows GET), Strict (blocks all cross-site requests including GET navigations), and None (allows cross-site, requires HTTPS Secure flag).

SameSite=Lax blocks cross-site POST, PUT, DELETE, and PATCH requests — the methods used for mutations. If your API uses GET only for reads and POST for all mutations, SameSite=Lax effectively prevents CSRF for SPAs in modern browsers. This is the baseline mitigation most applications rely on today.

The Double Submit Cookie pattern is a CSRF mitigation where the server sets a random CSRF token in a non-HttpOnly cookie. The client reads this cookie value and includes it as a custom request header (e.g., X-CSRF-Token). The server verifies the header value matches the cookie value. An attacker cannot read the cookie from a different origin, so they cannot set the correct header.

The Synchronizer Token Pattern generates a unique CSRF token per user session on the server. For HTML forms, the token is embedded in a hidden field. For SPA API calls, the token is provided via an endpoint or a meta tag and sent in a custom header. The server validates the token on every state-changing request.

A React SPA that stores its JWT in memory or localStorage and sends it in an Authorization: Bearer header is not vulnerable to classic CSRF. CSRF attacks exploit cookie-based authentication — an attacker's page cannot set custom headers on cross-origin requests due to CORS restrictions, so they cannot forge the Authorization header.

Simple cross-origin requests (form POST, image load) do not allow custom headers. Only requests that go through CORS preflight can include custom headers — and preflighted requests require explicit server permission. An API that requires a custom header (like X-Requested-With: XMLHttpRequest) for all mutations is inherently protected from simple CSRF attacks.

CORS controls which origins can read the response from a cross-origin request. CSRF is about which origins can make state-changing requests. Configuring CORS to restrict origins does not prevent CSRF — the browser still sends the request and the cookie, CORS only controls whether the response is visible to the JavaScript. A CSRF attack does not need to read the response.

Configure session cookies with: HttpOnly: true (prevents JavaScript from reading the cookie, blocking XSS-based token theft), Secure: true (only sent over HTTPS), SameSite: Lax or Strict (prevents CSRF), and an appropriate Max-Age or expiration. These four attributes together harden session management significantly.

Next.js App Router uses Server Actions, which are POST requests. Next.js implements CSRF protection by checking the Origin header against the host — requests from unexpected origins are rejected. This built-in check, combined with SameSite=Lax session cookies, provides solid CSRF protection for Server Action-based mutations.

Which SameSite cookie value blocks cross-site POST requests but allows cross-site GET navigations?

CSRF exploits cookie-based authentication by tricking the browser into sending authenticated cross-site requests. SameSite=Lax is the baseline defense for modern browsers. The Double Submit Cookie and Synchronizer Token patterns provide additional protection. React SPAs using JWT in Authorization headers are inherently CSRF-resistant. Custom required headers and CORS preflighting also mitigate CSRF. Always combine HttpOnly + Secure + SameSite on session cookies.