Cross-site request forgery protection makes the server verify that a state-changing browser request came from the intended application flow, not merely from a browser carrying valid cookies. Use built-in framework protection, anti-forgery tokens, appropriate SameSite cookies, and origin checks, while keeping authorization and reauthentication for sensitive actions.
Who this is for: Web developers maintaining cookie-authenticated applications they own and reviewers validating state-changing request protections.
- Apply request-integrity checks to every operation that changes data, permissions, money, sessions, or configuration.
- Use maintained framework mechanisms and bind tokens to the relevant session rather than inventing a token format.
- Treat SameSite and origin validation as useful layers, while preserving server authorization, recovery, and monitoring.
Identify state-changing browser routes
Inventory create, update, delete, upload, invitation, account, billing, and administrative endpoints reached from browsers. Include older forms, alternate HTTP methods, background requests, and compatibility routes. A read-looking route that changes last-used settings or triggers a job still needs protection. Safe retrieval routes should not mutate state as a side effect.
Determine how each route authenticates. Cookie credentials are automatically attached by browsers under defined conditions, which creates the core request-forgery concern. APIs using explicit authorization headers have a different exposure, but browser clients and cross-origin policy still need review. Do not remove one control merely because another client type is currently dominant.
Choose a maintained token pattern
Use the web framework's documented anti-forgery feature where available. Common patterns place an unpredictable value in the legitimate page or client state and require the same value on the state-changing request. The server validates it against the authenticated session or protected cookie. Follow current framework guidance for rotation, parallel tabs, and login transitions.
For stateless architectures, use an established signed double-submit pattern only when it fits the framework and threat model. Avoid plain duplicate cookies, predictable values, or tokens accepted from arbitrary locations. Keep token failures generic to users while recording a privacy-safe event that responders can correlate with route, session state, and origin evidence.
Layer cookies and origin checks
Set authentication cookies with Secure, HttpOnly, and an appropriate SameSite mode after testing real sign-in and integration flows. SameSite behavior varies with request context and does not replace a token in every architecture. Limit cookie domain and path scope, use short-lived sessions where practical, and rotate sessions after authentication changes.
Validate Origin on state-changing requests when the header is available, using an exact allow list rather than substring matching. Referer checks can be a carefully handled fallback under current OWASP guidance. Cross-origin resource sharing policy is not a CSRF defense by itself. Sensitive changes should also require current authorization and sometimes recent authentication.
Test legitimate and rejected flows
Write integration tests proving that valid forms and application requests succeed, while missing, invalid, or session-mismatched tokens fail without changing state. Cover login, logout, password and email changes, role changes, file operations, and administrative actions. Use synthetic accounts and an owned test environment rather than sending forged requests to unrelated sites.
Monitor repeated validation failures without logging token values. Confirm backups and rollback for high-impact state changes, and define escalation when failures coincide with unexpected account activity. Review routes, cookie behavior, framework updates, exceptions, and current OWASP advice quarterly. Any bypass exception needs an owner, compensating control, and expiration date.
Protect an authorized email-change flow
A team owns an account settings page where signed-in users can replace the email used for notices and recovery.
- Confirm the POST route is the only mutation path and that it checks the current user plus recent authentication.
- Enable the framework anti-forgery mechanism and include its token through the normal form helper.
- Set narrowly scoped secure session cookies and validate the exact application origin on the server.
- Test valid, missing-token, wrong-session, expired-session, and unauthorized-account cases with synthetic users in staging.
- Log the outcome without secrets, notify the existing address, support reversal, and document incident escalation.
State-change protection checklist
Complete this checklist for each browser-accessible mutation endpoint.
- Route inventory: action, method, client, authentication mechanism, data changed, and consequence.
- Integrity control: framework feature, token location, session binding, validation rule, and failure response.
- Cookie and origin: flags, scope, SameSite choice, exact origin allow list, and integration exceptions.
- Authorization and recovery: object check, recent authentication, notification, reversal, backup, and owner.
- Evidence: approved environment, synthetic tests, protected logs, alerts, exception expiry, and quarterly review.
Common mistakes
- Using GET for a mutation and assuming a hidden link makes the operation safe.
- Relying only on SameSite defaults without checking application integrations and current browser behavior.
- Accepting a token without tying it to the relevant session or preserving authorization on the target object.
Try one
An application has cookie-authenticated POST routes for changing a shipping address and exporting account data. Define the defensive review.
A complete answer inventories both routes, enables maintained anti-forgery validation, checks exact origin and cookie scope, and enforces object authorization plus recent authentication where consequence warrants it. It tests valid and rejected requests with synthetic accounts in staging, verifies no state or export occurs on failure, protects logs, confirms recovery or revocation options, and names the escalation owner.
Sources
- OWASP Cross-Site Request Forgery Prevention Cheat SheetOWASP patterns for authenticating state-changing browser requests.
- CISA Secure by DesignCISA guidance for making customer security a core product requirement.