CSRF
Cross-Site Request Forgery (CSRF) is an attack that tricks an authenticated user into performing unintended actions on a web application by sending forged requests from another site.
§ 1 Definition
CSRF exploits the trust a web application has in an authenticated user's browser. If a user is logged into their banking site and visits an attacker-controlled page, that page can submit a hidden form to the bank's transfer endpoint. Since the browser automatically sends the bank's session cookie with the request, the server sees a legitimate authenticated request. CSRF attacks change state (transfer money, change email, post content) but cannot read responses due to the same-origin policy.
§ 2 How CSRF Works
CSRF relies on the browser's automatic inclusion of credentials (cookies, IP-based auth) with every request to a domain. An attacker creates a page that submits a form or sends an AJAX request to a target site. When the authenticated victim visits the attacker's page, the forged request executes with the victim's session. The server cannot distinguish the forged request from a legitimate one because it carries valid authentication.
§ 3 CSRF Prevention Techniques
CSRF tokens: Server-generated unique tokens embedded in forms and verified on submission. SameSite cookies: Setting SameSite=Strict or SameSite=Lax on session cookies prevents the browser from sending them on cross-origin requests. Custom request headers: Requiring a non-standard header (e.g., X-Requested-With) that cannot be set cross-origin without CORS.
§ 4 SameSite Cookies Impact
The SameSite cookie attribute (RFC 6265bis) has changed the CSRF landscape. With SameSite=Lax (the default in modern browsers for cookies without an explicit SameSite attribute), cookies are only sent for top-level navigations using safe methods (GET). POST forms from cross-origin pages no longer include cookies. SameSite=Strict blocks all cross-origin cookie sending, including links. This has made common CSRF attack patterns less viable, but CSRF is not dead: SameSite does not protect against subdomain attacks.
§ 5 Note
§ 6 Common questions
- Q. Is CSRF still a threat with modern browsers?
- A. Yes, but SameSite cookies (Lax by default) have significantly reduced the attack surface. CSRF is still relevant for subdomain attacks and sites with SameSite=None.
- Q. Does a REST API need CSRF protection?
- A. If your API uses cookie-based authentication, yes. If your API uses Bearer JWT or API keys in Authorization headers, CSRF does not apply because the browser does not automatically attach these.
- Q. What is the difference between XSS and CSRF?
- A. XSS injects malicious scripts into a trusted page. CSRF forges requests from an untrusted page against a trusted site.
- CSRF tricks authenticated users into performing unintended actions.
- Primary defenses: CSRF tokens, SameSite cookies, custom headers.
- SameSite=Lax (default in modern browsers) blocks most CSRF vectors.
- CSRF protects state-changing requests, not read operations.
Atomic Glue includes SameSite cookie configuration in every project, implements CSRF token middleware for cookie-authenticated endpoints, and audits session handling. See Trust & Security.
Get in touchCross-Site Request Forgery (CSRF) is an attack that tricks an authenticated user into performing unintended actions on a web application by sending forged requests from another site.
Category: Security (also: Web Development)
Author: Atomic Glue Security Team
## Definition
CSRF exploits the trust a web application has in an authenticated user's browser. If a user is logged into their banking site and visits an attacker-controlled page, that page can submit a hidden form to the bank's transfer endpoint. Since the browser automatically sends the bank's session cookie with the request, the server sees a legitimate authenticated request. CSRF attacks change state (transfer money, change email, post content) but cannot read responses due to the same-origin policy.
## How CSRF Works
CSRF relies on the browser's automatic inclusion of credentials (cookies, IP-based auth) with every request to a domain. An attacker creates a page that submits a form or sends an AJAX request to a target site. When the authenticated victim visits the attacker's page, the forged request executes with the victim's session. The server cannot distinguish the forged request from a legitimate one because it carries valid authentication.
## CSRF Prevention Techniques
**CSRF tokens**: Server-generated unique tokens embedded in forms and verified on submission. **SameSite cookies**: Setting SameSite=Strict or SameSite=Lax on session cookies prevents the browser from sending them on cross-origin requests. **Custom request headers**: Requiring a non-standard header (e.g., X-Requested-With) that cannot be set cross-origin without CORS.
## SameSite Cookies Impact
The SameSite cookie attribute (RFC 6265bis) has changed the CSRF landscape. With SameSite=Lax (the default in modern browsers for cookies without an explicit SameSite attribute), cookies are only sent for top-level navigations using safe methods (GET). POST forms from cross-origin pages no longer include cookies. SameSite=Strict blocks all cross-origin cookie sending, including links. This has made common CSRF attack patterns less viable, but CSRF is not dead: SameSite does not protect against subdomain attacks.
## Note
XSS can defeat CSRF protections. If an attacker can run JavaScript on your domain, they can read CSRF tokens from the page and include them in forged requests.
## Common questions
Q: Is CSRF still a threat with modern browsers?
A: Yes, but SameSite cookies (Lax by default) have significantly reduced the attack surface. CSRF is still relevant for subdomain attacks and sites with SameSite=None.
Q: Does a REST API need CSRF protection?
A: If your API uses cookie-based authentication, yes. If your API uses Bearer JWT or API keys in Authorization headers, CSRF does not apply because the browser does not automatically attach these.
Q: What is the difference between XSS and CSRF?
A: XSS injects malicious scripts into a trusted page. CSRF forges requests from an untrusted page against a trusted site.
## Key takeaways
- CSRF tricks authenticated users into performing unintended actions.
- Primary defenses: CSRF tokens, SameSite cookies, custom headers.
- SameSite=Lax (default in modern browsers) blocks most CSRF vectors.
- CSRF protects state-changing requests, not read operations.
## Related entries
- [XSS](atomicglue.co/glossary/xss)
- [Cookie Attributes (Secure/HttpOnly/SameSite)](atomicglue.co/glossary/cookie-attributes)
- [JWT](atomicglue.co/glossary/jwt-backend)
Last updated December 2024. Permalink: atomicglue.co/glossary/csrf