prevent-cross-site-request-forgery

name	prevent-cross-site-request-forgery
category	web
description	Prevent cross-site request forgery with deliberate cookie behavior, request tokens, and origin verification. Use when browser credentials are attached automatically to state-changing requests.

prevent-cross-site-request-forgery

Require evidence that a consequential browser request originated from an authorized application context.

Procedure

1. Inventory every state-changing route, including login, logout, uploads, GraphQL mutations, and legacy forms.
2. Identify which credentials browsers attach automatically and which flows must operate cross-site.
3. Set the strictest workable SameSite cookie policy as one defense layer.
4. Add a proven synchronizer-token or signed double-submit pattern to applicable requests.
5. Validate Origin and, where appropriate, Referer against an exact allowlist on the trusted server.
6. Keep safe methods free of side effects and reject simple-content-type workarounds where feasible.
7. Treat CORS as a browser read policy, not as a replacement for CSRF protection.
8. Cover subdomains, redirects, embedded frames, login CSRF, and session transitions in the design.
9. Test missing, stale, cross-session, attacker-supplied, and duplicated tokens in real browser flows.
10. Monitor rejections without recording token values.

Guardrails

• Never put a CSRF token in a URL or a broadly shared cache key.
• XSS can bypass many CSRF controls, so both classes require independent prevention.
• Do not exempt a route merely because its request body is JSON.

Done

• A route inventory maps each state change to its CSRF controls
• Browser tests verify legitimate and hostile cross-site flows
• Rejection logs are recorded and reconciled without exposing tokens