CSRF: Protecting Authenticated State Changes
Cross-site request forgery tricks a browser into making an unwanted request using credentials it attaches automatically, often cookies.
- Author
- absequ
- Published
- Updated
- Category
- Security
- csrf
- security
- practical guide
Cross-site request forgery tricks a browser into making an unwanted request using credentials it attaches automatically, often cookies. A victim can be authenticated without intentionally authorizing the requested action. The attacker does not need to read the response for a state-changing operation to cause harm.
On this page
The mental model
Separate the origin of a request from the identity represented by its credentials. A valid session cookie establishes a session, not the user's intention to submit a particular form from a trusted origin. An endpoint that updates an email address or transfers a resource needs protection against unwanted cross-site invocation as well as normal authorization.
Do not use GET for state changes. Links can be prefetched, scanned or followed by automated clients. A confirmation page can load safely on GET, while the explicit change uses a protected method. This distinction is especially important for email links and unsubscribe flows.
A practical workflow
Use the CSRF mechanism supplied by a suitable framework when available, and understand its assumptions. Token-based defenses bind a submitted value to the session or another authenticated context. Origin/Referer validation and Fetch Metadata can add useful checks. SameSite cookies reduce some cross-site credential sending but need deployment-specific analysis rather than being treated as a universal substitute.
CORS is not a general CSRF defense: a browser may be able to send a request even when script cannot read its response. Consider simple form submissions and accepted content types. Review all mutation endpoints, including aliases and older routes, because one forgotten path can bypass an otherwise consistent policy.
Worked example
For a cookie-authenticated account mutation:
1. Require an authenticated session and operation-specific permission.
2. Reject unsafe request origins according to the application's policy.
3. Validate the framework/session-bound CSRF token.
4. Validate the submitted fields and apply the change once.
5. Return a useful result without logging session or CSRF tokens.
This is a control sequence, not a replacement CSRF implementation.Test the public behavior using an owned test environment. An intended form submission should succeed, while a request missing the token or using a token from a different session should fail. Add a cross-origin form test and a case where a user lacks permission even with a valid CSRF token. CSRF validation must not become an accidental authorization bypass.
Preserve ordinary recovery flows. A rejected request should offer a safe way to reload or retry without exposing internal token values. Decide how multiple tabs and expired sessions behave. Reliability matters because a control that routinely breaks real forms is likely to be disabled later.
Failure modes and security
XSS can undermine browser-side protections by acting within the legitimate origin, so CSRF and XSS defenses are complementary. Do not put sensitive tokens into URLs that can leak through history, referrers or logs. Keep cookie flags and session lifetimes aligned with the application's authentication model.
A public endpoint without ambient authentication can still be abused, but not every form-abuse problem is CSRF. Rate limiting, CAPTCHA, spam detection and business validation solve other risks. Identify the actual credential and trust mechanism before choosing controls.
Practice and verification
Draw the request sequence for a profile-update form. Mark which credentials the browser sends automatically and which value proves the request came through the intended flow. Exercise legitimate, expired, missing-token, wrong-session and unauthorized cases. Document any reverse-proxy origin handling, because an origin check that trusts arbitrary forwarded headers can be misleading. Do not test with real account-changing operations in production.
References
OWASP CSRF prevention — OWASP
MDN SameSite cookies — MDN