Cross-site request forgery abuses a browser that is already authenticated. A malicious page causes the browser to send a state-changing request, and ambient cookies may make it look legitimate.
Protect state changes
- Use unpredictable anti-CSRF tokens tied to the session.
- Set appropriate SameSite cookie attributes.
- Validate Origin or Referer for sensitive requests.
- Require reauthentication for high-impact changes.
- Never change state through GET requests.
APIs need context
An API using Authorization headers instead of cookies has a different exposure. CORS is not a universal CSRF defence, and XSS can defeat many in-page controls.
Test like a browser
Verify forms, JSON endpoints, multipart uploads and logout. Framework defaults help only when developers use the intended middleware correctly.
Login CSRF exists too
An attacker may cause a victim to sign into the attacker's account, then collect information the victim unknowingly adds. Protect login and account-linking endpoints, not only obvious payment actions.
Token handling
Do not place anti-CSRF tokens in URLs where logs and referrers may capture them. Compare tokens in constant time where appropriate and rotate them with session boundaries.
Design state changes so browsers cannot trigger them casually
Use POST, PUT, PATCH or DELETE for mutations; never change account state through a GET link. Add framework-supported anti-CSRF tokens for cookie-authenticated forms and APIs, validate Origin or Referer where appropriate, and use SameSite cookies as defence in depth.
APIs need a precise threat model
A bearer token supplied in an Authorization header is not automatically sent cross-site like a cookie, but unsafe storage can expose it to XSS. If the API authenticates with cookies, CORS does not replace CSRF protection. Protect login, logout and account-linking flows as well as payments.
Test with a page hosted on a different origin and confirm that the server rejects a forged action. A hidden form that “looks impossible” is still a valid attack tool.
Protect every request that changes state
CSRF works when a browser automatically attaches a user's credentials to a request initiated elsewhere. Inventory create, update, delete, payment and account actions, including endpoints that incorrectly change state through GET. Reading a page should never trigger a sensitive mutation.
For cookie-authenticated web applications, use unpredictable anti-CSRF tokens tied to the session or a carefully implemented double-submit design. Validate the token on the server. Checking that a field merely exists provides no protection.
Add independent signals and safe failure behavior
Use SameSite cookies as another layer, and validate Origin or Referer where the request model permits it. JSON APIs should require explicit content types and avoid permissive CORS credentials. None of these replaces authorization for the requested object and action.
On failure, return a clear error without revealing token values. Log the route and reason using a request identifier, not secrets. Test normal forms, expired sessions, multiple tabs and cross-origin attempts. A defense that breaks recovery or checkout will eventually be bypassed by an emergency exception.
Mobile clients and background jobs may use another authentication model. Exclude them only after confirming they do not rely on ambient browser cookies, then protect replay and authorization independently.