CSRF protection that you understand and can implement today

I spent three hours debugging a weird session timeout issue last month, only to realize I’d accidentally botched the SameSite cookie configuration in our staging environment. It’s a humbling reminder that CSRF protection—while conceptually simple—is surprisingly easy to break when you’re moving fast.

Cross-Site Request Forgery (CSRF) tricks an authenticated user into executing unwanted actions on a web application where they're currently logged in. If you aren't careful, a malicious site can leverage the user's browser session to POST data to your API without their consent.

Why CSRF protection is still relevant

Most developers think that because they use JWTs or modern frameworks, they’re automatically safe. That’s a dangerous assumption. If your authentication relies on browser-stored cookies, you are vulnerable unless you explicitly defend against it. We used to rely heavily on hidden anti-forgery tokens injected into every form. While those work, they’re clunky to manage in a decoupled architecture where your frontend is a SPA and your backend is a stateless API.

Before we dive into the "best" way, let’s talk about the wrong turn we took in a previous project. We tried to implement a custom header-based check for every single request. It broke because we forgot to account for pre-flight OPTIONS requests in our CORS middleware. We spent about two days wrestling with browser security policies before we realized we were overcomplicating things.

The modern approach: SameSite cookies

The most effective CSRF protection strategy today is leveraging the SameSite attribute on your session cookies. It’s a browser-level defense that prevents cookies from being sent in cross-site requests.

You should set your cookies to SameSite=Lax or SameSite=Strict.

• Strict: The cookie is only sent if the request originates from the same site where the cookie was set.
• Lax: The cookie is withheld on cross-site subrequests (like images or frames) but sent when a user navigates to the origin site (like clicking a link).

For most apps, Lax is the sweet spot. It prevents the common "drive-by" POST request while keeping your site usable when users click links from their email or social media.

When you need more than just cookies

Sometimes, you need an extra layer, especially for high-stakes actions like changing a password or transferring funds. This is where the Synchronizer Token Pattern remains king.

Here is how I implement it when I need guaranteed security:

1. The server generates a cryptographically strong, random token.
2. The server stores this token in the user’s session.
3. The frontend retrieves this token (usually via a meta tag or a dedicated /csrf-token endpoint).
4. Every state-changing request (POST, PUT, DELETE) must include this token in a custom HTTP header, like X-CSRF-TOKEN.

JAVASCRIPT
// Example of adding the token to an Axios instance
const apiClient = axios.create({
  headers: {
    CE9178">'X-CSRF-TOKEN': document.querySelector(CE9178">'meta[name="csrf-token"]').content
  }
});

This ensures that even if a browser sends a cookie automatically, the request will fail because the attacker cannot read the token from your domain due to the Same-Origin Policy (SOP).

Practical tips for your stack

If you’re working with TypeScript, you can use TypeScript utility types you will reach for weekly to enforce that your API request objects always include the necessary security headers. It’s a small change that prevents a lot of "forgot to include the token" bugs during development.

If you’re building a high-performance dashboard, you might be tempted to skip these checks to save a few milliseconds. Don't. Even if you're using React Performance Patterns You Actually Need in 2025, security headers add negligible overhead—usually around 1-2ms of processing time—which is a fair trade for preventing an account takeover.

Common Questions

Do I need CSRF protection if I use JWTs in LocalStorage? Technically, no, because LocalStorage isn't automatically sent by the browser. However, you are now vulnerable to XSS. If an attacker can run JavaScript on your page, they can steal the JWT. This is why many engineers prefer HttpOnly cookies, which brings us right back to needing CSRF protection.

Is SameSite=Lax enough? For 90% of apps, yes. If you are building a banking app or something that handles sensitive data, add the Synchronizer Token Pattern on top of Lax cookies for defense-in-depth.

Does this affect my mobile app? If your mobile app uses the same API, the browser-based CSRF protections don't apply. You'll need to ensure your API handles authentication via Authorization: Bearer <token> headers instead of cookies for those clients.

I’m still debating whether it’s worth moving entirely to Strict cookies for our next project. It would break deep-linking from external sites, which is a UX nightmare, but the security posture would be near-perfect. For now, I’m sticking with Lax and keeping a close eye on our audit logs. Security is a constant trade-off between convenience and paranoia.