What are possible reasons for CSRFTokenMismatchError?

[antonykamp]

We are currently experiencing a consistent number of CSRFTokenMismatchError messages. We cannot reproduce this issue locally, which is why I wanted to ask: What are possible reasons for CSRFTokenMismatchError? Is it possible that this is intended?

[manimovassagh]

There are several common causes for CSRFTokenMismatchError in production that don't reproduce locally:

1. Cookie domain / secure flag mismatch

Blitz sets the CSRF token in a cookie. If your production setup has any of these, the cookie might not be sent back:

• Your app is behind a reverse proxy that strips or rewrites cookies
• The Set-Cookie domain doesn't match the request origin
• Secure flag is set but some requests come over HTTP (e.g., health checks, internal redirects before TLS termination)

2. CDN or load balancer caching

If a CDN (CloudFront, Vercel Edge, etc.) caches HTML pages that contain the CSRF token, multiple users could end up with the same embedded token but different session cookies. Check that your HTML responses have Cache-Control: no-store or are excluded from edge caching.

3. Multiple tabs / stale tokens

If a user has your app open in multiple tabs and one tab triggers a session refresh, the CSRF token in the other tab becomes stale. This is especially common if your sessions have short expiry times.

4. Browser extensions or privacy settings

Extensions like uBlock Origin, Privacy Badger, or strict Safari ITP can block or partition cookies, preventing the CSRF cookie from being sent with requests. This is "intended" from the browser's perspective but causes CSRF mismatches.

5. Cross-origin requests

If your frontend and API are on different subdomains (e.g., app.example.com and api.example.com), SameSite=Lax cookies won't be sent on cross-origin POST requests.

To debug in production:

// Add logging to see what's happening
import { middleware } from "blitz"

export default middleware(async (req, res, next) => {
  console.log("CSRF cookie present:", !!req.cookies["sAntiCrfToken"])
  console.log("CSRF header present:", !!req.headers["anti-csrf"])
  console.log("Origin:", req.headers.origin)
  await next()
})

In most production cases I've seen, it's either #1 (reverse proxy eating cookies) or #4 (privacy-focused browsers). Check your proxy config first - make sure it forwards Cookie and Set-Cookie headers untouched.

[tamish-max]

Yes — this can absolutely be "intended" in the sense that Blitz is rejecting a request whose CSRF token and CSRF cookie no longer match.

The common production-only causes are usually one of these:

1. Cookie / domain / proxy mismatch
   Reverse proxies, subdomain differences, TLS termination, or rewritten Set-Cookie headers can cause the anti-CSRF cookie not to come back exactly as expected.

2. Cached HTML with an old token
   If any CDN / edge / proxy layer caches HTML that embeds a token, users can submit a stale token while sending a different cookie.

3. Multiple tabs / session refresh
   One tab refreshes or rotates session state, another tab submits an old form.

4. Cross-origin setup
   If frontend and backend are on different origins / subdomains, cookie SameSite and Secure settings become very important.

5. Browser privacy features / extensions
   Safari ITP, Firefox strict mode, privacy extensions, etc. can suppress or partition cookies.

What I would log in production for failing requests:

• request origin / host
• whether the anti-CSRF cookie is present
• whether the anti-CSRF header/body value is present
• forwarded proto / proxy headers
• whether the response that served the page was cached

In my experience, the two biggest culprits are proxy/cookie config and cached HTML. I would start there first.