AI-Generated CSRF Protection Review Rules

Purpose

Use these rules when an AI coding assistant writes or edits code that performs a state-changing action for an authenticated user. The goal is to stop a generated handler or form from shipping a cross-site request forgery hole just because it works in tests and looks like ordinary request handling.

This is a review policy, not a CSRF tutorial. It tells reviewers what must be true about a generated change's request methods, token handling, cookie posture, and origin checks before the change is safe to merge.

Review Inputs

Collect enough context to know how the request is authenticated and what it does.

• The HTTP method and route of every handler the change adds or edits.
• How the user is authenticated on that route: cookie-based session, bearer token in a header, or something else.
• Whether the framework has built-in CSRF protection and whether this route opts in or out of it.
• The cookie attributes set for session and auth cookies (SameSite, Secure, HttpOnly).
• Whether the operation changes server state or is purely read-only.

State-Changing Method Rules

• Treat any operation that creates, updates, deletes, or otherwise changes state as unsafe and require POST, PUT, PATCH, or DELETE.
• Never perform a state change on GET or HEAD; those can be triggered by a link, image, prefetch, or preload without any script.
• Do not rely on a hidden form field or request body alone to make a GET "non-idempotent"; the method itself must be unsafe.
• Make read endpoints side-effect free so they do not need CSRF defenses and cannot be abused as state changes.

Token And Origin Rules

• For cookie-authenticated unsafe requests, require a synchronizer (anti-CSRF) token or a double-submit cookie; ambient session cookies are not a defense.
• Generate tokens with a cryptographically secure random source, tie them to the user session, and make them unpredictable.
• Validate the token server-side on every unsafe request using a constant-time comparison, and reject when it is missing, empty, or mismatched.
• Validate the Origin header against an allowlist for unsafe requests, falling back to Referer, and reject cross-site or missing origins rather than trusting them.
• For AJAX/fetch APIs, a required custom header (for example X-Requested-With or X-CSRF-Token) adds a check that simple cross-site form posts cannot set.

Cookie And Session Rules

• Set session and auth cookies with SameSite=Lax or SameSite=Strict, plus Secure and HttpOnly.
• Treat SameSite as defense in depth, not the only control: Lax still allows top-level GET navigation and enforcement varies across clients.
• Prefer non-cookie credentials (a bearer token sent in an Authorization header) for pure APIs, since they are not attached automatically cross-site.
• When both a cookie session and a token exist, confirm the unsafe path actually checks the token and does not silently accept the cookie alone.

Merge Blockers

Block merge when any of these is true.

• A state-changing operation is reachable over GET or HEAD.
• A cookie-authenticated unsafe request has no anti-CSRF token, double-submit cookie, or verified origin.
• A CSRF token is generated but never validated server-side, or is compared with a non-constant-time check.
• Session or auth cookies are set without SameSite and without any compensating CSRF control.
• Login, logout, or password/email change flows lack CSRF protection.
• The token is exposed in a URL, log line, or referer-leaking link.

Review Checklist

• {"task": "Unsafe methods only", "description": "Every state change uses POST/PUT/PATCH/DELETE, never GET or HEAD"}
• {"task": "CSRF defense present", "description": "Cookie-authenticated unsafe requests require a token, double-submit cookie, or verified origin"}
• {"task": "Token validated", "description": "The anti-CSRF token is checked server-side with a constant-time comparison and tied to the session"}
• {"task": "Cookies hardened", "description": "Session/auth cookies set SameSite, Secure, and HttpOnly"}
• {"task": "Origin checked", "description": "Origin/Referer is validated against an allowlist for unsafe requests"}
• {"task": "Sensitive flows covered", "description": "Login, logout, and credential-change flows are CSRF protected and tokens never leak"}

AI Review Rules

AI assistants can write and review request handlers, but they should show their evidence.

• Ask the assistant to list every state-changing route in the change and its HTTP method before judging safety.
• Require the assistant to state how each cookie-authenticated route is protected against CSRF rather than only confirming the happy path works.
• Have the assistant show where the token is generated, where it is validated, and that the comparison is constant time.
• Do not let the assistant claim SameSite cookies alone make a route CSRF-safe.
• Re-run review after any change to authentication, cookie attributes, request methods, or token handling.

Troubleshooting

• The form submits but the action never fires cross-site: that is expected when CSRF protection works; confirm a forged cross-site request is rejected, not just that the legitimate form succeeds.
• The token check passes with an empty token: the validator is likely treating missing or empty as valid; reject empty, missing, and mismatched tokens explicitly.
• It works in tests but not in the browser: tests may send the token automatically; verify a real cross-site request without the token is blocked.
• SameSite seems to break a legitimate redirect flow: prefer Lax for session cookies and keep a token check rather than dropping SameSite entirely.

Duplicate And History Check

Before adding or changing CSRF handling, confirm the framework does not already provide protection that this change is bypassing. Many frameworks enable CSRF middleware by default; a generated handler that opts out, disables the middleware, or rolls its own token should be treated as suspicious. Check whether an existing shared helper already issues and validates tokens before introducing a parallel mechanism.

Defense Reference

Sources

• OWASP Cross-Site Request Forgery Prevention Cheat Sheet
• OWASP CSRF attack reference
• MDN Web Docs: CSRF glossary and SameSite cookies
• CWE-352: Cross-Site Request Forgery
• PortSwigger Web Security Academy: CSRF

• Source repositorygithub.com 2026-06-22T09:58:37-07:00
• Documentationcheatsheetseries.owasp.org
• Submitted by jaso0n08182026-06-22