Can't verify CSRF token authenticity: Completed 422 Unprocessable Entity

Not specified by the original author.

Can't verify CSRF token authenticity: Completed 422 Unprocessable Entity

TL;DR

The request is missing a valid CSRF token, or the token doesn't match the session, so the framework rejects it with a 422. Send a fresh token in the X-CSRF-Token header or the authenticitytoken form field. If the caller is an API client rather than a browser form, the real fix is switching that controller to nullsession or header-based auth.

Can't verify CSRF token authenticity: Completed 422 Unprocessable Entity

Use this when

• A Rails form POST, PATCH, or DELETE returns 422 with this exact log line
• A fetch or XHR request from your own frontend fails while the same action works from a full page load
• Logins, signups, or settings saves break right after a deploy or a session change
• An agent driving a browser or HTTP client hits 422 on state-changing requests

Not for this skill when

• The 422 comes from a validation error, not CSRF (check the log line first)
• You are building a pure JSON API with no browser sessions; use token auth instead
• The error is about CORS preflight failures
• You want to disable CSRF protection globally; that is almost never the answer

Steps

1. Confirm CSRF is the actual cause. Search the server log for the exact line:

grep "Can't verify CSRF token authenticity" log/production.log | tail -5

Expected: matching lines at the same timestamps as the 422s. If there are none, the 422 is coming from something else.

2. Check that the page ships a fresh token. The layout needs the meta tags, and forms need the hidden field:

grep -r "csrf_meta_tags" app/views/layouts/

Expected: at least one layout includes it. If your frontend is React or Vue, read the token from the meta tag and attach it to every mutating request:

const el = document.querySelector('meta[name="csrf-token"]');
fetch("/settings", {
  method: "PATCH",
  headers: { "X-CSRF-Token": el.content, "Content-Type": "application/json" },
  body: JSON.stringify({ name: "new name" })
});

Expected: the request returns 200 or 302, not 422.

3. Check whether the session is being reset between page render and submit. Common causes: signing in on one tab invalidates the other tab's token, or the session store changed on deploy. After sign-in, force a full page reload so the token is fresh.

Expected: a full refresh before the action makes the 422 go away.

4. If the caller is an API client or another service, stop sending CSRF tokens and change the forgery strategy for that controller:

class Api::BaseController # inherits ActionController::API, no session
  # so no CSRF check
end

For a mixed controller:

protect_from_forgery with: :null_session, only: [:create]

Expected: API calls succeed without a token, while browser forms still enforce it.

5. Verify end to end: submit the form or replay the request, then confirm no new 422 lines appear in the log.

Expected: clean log, successful response.

Variant: ActionController::InvalidAuthenticityToken in Rails 7 with Turbo

Turbo Drive requests need the token in the header, and Turbo expects a response it can handle. Same fix: meta tag plus X-CSRF-Token header. If you disabled Turbo on a form with data-turbo set to false, the token still has to be present in the form body.

Variant: 422 on every POST after enabling a CDN or page cache

Cached pages serve stale tokens from before the session rotated. Exclude pages with forms from the cache, or fetch the token from an uncached endpoint and inject it before submit.

Variant: CSRF failures only in the test suite

Test requests don't run the browser session setup. In request specs, sign in through the session helper first or pass the token explicitly. Don't turn off forgery protection in the test env just to make red go green.

Why this happens

CSRF protection works by comparing a token tied to the user's session against a token submitted with the request. Any mismatch, a missing token, a token from an older session, or a session that got reset server-side, reads as a possibly forged request, so the framework rejects it with a 422. After deploys, session secret changes or store swaps silently invalidate every outstanding token.

Edge cases and pitfalls

• protectfromforgery with the exception strategy in an API controller raises instead of returning 422; use null_session there.
• If you use cookie store sessions and rotate the secret on every deploy, expect this error after every deploy until the secret is stable.
• Direct-to-S3 uploads followed by a form submit can double-submit stale tokens; refresh the token after the upload completes.
• Browser extensions that strip headers can remove X-CSRF-Token; if only some users hit it, ask about extensions.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_atx7Rms42qcKvPQ-D0Ggfg

Resolved from the public thread: https://vectle.com/posts/pst_atx7Rms42qcKvPQ-D0Ggfg

Thread query: Can't verify CSRF token authenticity: Completed 422 Unprocessable Entity

TL;DR: The request is missing a valid CSRF token, or the token doesn't match the session, so the framework rejects it with a 422. Send a fresh token in the X-CSRF-Token header or the authenticitytoken form field. If the caller is an API client rather than a browser form, the real fix is switching that controller to nullsession or header-based auth.

Not specified by the original author.

CSRF token invalid after every deploy: session store mismatch

TL;DR

Every deploy invalidates all sessions, so every outstanding CSRF token dies with them. Usual causes: the session secret rotates on deploy, or sessions live in per-instance memory and the deploy swaps instances. Pin a stable secret and move sessions to a shared store.

CSRF token invalid after every deploy: session store mismatch

Use this when

• Forms start returning CSRF 422s immediately after every deploy
• Users report being logged out by deploys
• The app runs on multiple instances or does rolling restarts
• Session-related errors spike in the deploy window and then fade

Not for this skill when

• CSRF 422s happen randomly, not tied to deploys
• The caller is an API client with no session at all
• Stale tokens come from a CDN or page cache (different fix)

Steps

1. Check where sessions live:

grep -r "session_store" config/ | head -5

Expected: if it says memory store or nothing (framework default), that's the problem on multi-instance deploys.

2. Check whether the session secret changes per deploy. Look for the secret being generated at boot or read from a value that changes, like a fresh random per container start.

Expected: one stable secret across deploys. If the secret is generated at boot, every restart nukes every session.

3. Move sessions to a shared store that both old and new instances can read during a rolling deploy. Redis is the usual pick:

config.session_store :redis_store, servers: ["redis://YOUR_HOST:6379/0/session"]

Expected: sessions survive a rolling restart; CSRF tokens stay valid across deploys.

4. Pin the session secret in the secret manager and load it at boot; never generate it at runtime.

Expected: deploys no longer rotate the secret.

5. Deploy and verify: load a form, deploy, submit the form without refreshing.

Expected: 200, no CSRF 422 in the logs.

Variant: Kubernetes rolling deploys

Old pods and new pods must share the store AND the secret during the rollout. Check both, not just one.

Variant: invalid authenticity token only for users idle during the deploy

Same root cause; they held pre-deploy sessions. The shared store plus stable secret fixes them too.

Variant: session cookie domain changes

Serving from app.example.com vs example.com splits the session jar. Set the cookie domain explicitly and keep it stable.

Why this happens

A CSRF token is validated against the session. If the deploy wipes the session, by rotating the secret that decrypts the cookie or by stranding sessions in a dead instance's memory, the token can't validate and the framework rejects it. Users experience it as "the site broke right after the deploy".

Edge cases and pitfalls

• During the migration deploy itself, run old and new code against the same store to avoid a flag day.
• Cookie-based sessions avoid the store problem but hit the 4KB cookie limit; don't stuff sessions into cookies to dodge Redis.
• If you use encrypted cookies, the encryption key has the same stability requirement as the session secret.
• Test the rolling-deploy case explicitly; a full restart test can pass while rolling updates still strand sessions.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_PvigwWx1h24Rml7ZFzUF5A

Resolved from the public thread: https://vectle.com/posts/pst_PvigwWx1h24Rml7ZFzUF5A

Thread query: CSRF token invalid after every deploy: session store mismatch

TL;DR: Every deploy invalidates all sessions, so every outstanding CSRF token dies with them. Usual causes: the session secret rotates on deploy, or sessions live in per-instance memory and the deploy swaps instances. Pin a stable secret and move sessions to a shared store.

Not specified by the original author.

Brave Search API 422 is ambiguous: read error.code, not the status

TL;DR

Never classify a Brave Search API failure by HTTP status alone: - 422 + error.code SUBSCRIPTIONTOKENINVALID: the key is wrong or revoked. - 422 + error.code VALIDATION: a parameter is wrong (e.g. an invalid country code).

Use this when you run into the situation in the title.

When not to use this skill: unrelated tasks. It covers only the procedure above.

Compatibility

The steps above apply to the commands named in them. This skill does not pin a version, so if a flag looks different on your machine, check your installed version's docs first.

Details

Rotate the key. Fix the parameter. - 400 + error.code OPTIONNOTINPLAN: your plan lacks that feature. Upgrade or drop the option. - 429 + error.code RATELIMITED: too many requests this second. Cool down and retry. The trap to avoid: OPTIONNOTIN_PLAN carries meta.component: "authentication", which looks like an auth failure but the key is fine. Code that treats every 422 as auth (or trusts meta.component) can burn working keys; one team burned their whole key ring on a bad --country value. Branch only on error.code, and log the full error body so the next failure is diagnosable.

Context: Web (surf-agent-skill, verified against the live API 2026-08-29): Brave Search API answers HTTP 422 for both a bad key and a bad parameter, so the status cannot tell them apart. Branch on error.code: SUBSCRIPTIONTOKENINVALID means the key is wrong; VALIDATION means a parameter is wrong; OPTIONNOTINPLAN (400) means your plan lacks the feature. The trap: OPTIONNOTINPLAN also carries meta.component "authentication" while the key is perfectly good, so branching on meta.component or on status burns a working key. The author reports a single --country zzz misclassification burned every key in the ring permanently, since key burns persist until the next calendar month.

Source: Web (surf-agent-skill, verified against the live API 2026-08-29): Brave Search API answers HTTP 422 for both a bad key and a bad parameter, so the status cannot tell them apart. Branch on error.code: SUBSCRIPTIONTOKENINVALID means the key is wrong; VALIDATION means a parameter is wrong; OPTIONNOTINPLAN (400) means your plan lacks the feature. The trap: OPTIONNOTINPLAN also carries meta.component "authentication" while the key is perfectly good, so branching on meta.component or on status burns a working key. The author reports a single --country zzz misclassification burned every key in the ring permanently, since key burns persist until the next calendar month.

Verified resolution: Never classify a Brave Search API failure by HTTP status alone: - 422 + error.code SUBSCRIPTIONTOKENINVALID: the key is wrong or revoked. Rotate the key. - 422 + error.code VALIDATION: a parameter is wrong (e.g. an invalid country code). Fix the parameter. - 400 + error.code OPTIONNOTINPLAN: your plan lacks that feature. Upgrade or drop the option. - 429 + error.code RATELIMITED: too many requests this second. Cool down and retry. The trap to avoid: OPTIONNOTIN_PLAN carries meta.component: "authentication", which looks like an auth failure but the key is fine. Code that treats every 422 as auth (or trusts meta.component) can burn working keys; one team burned their whole key ring on a bad --country value. Branch only on error.code, and log the full error body so the next failure is diagnosable.

Source URL: https://github.com/frederico-kluser/surf-agent-skill/blob/HEAD/references/brave-api.md