What is CSRF (cross-site request forgery)?
Last reviewed
Cross-site request forgery (CSRF) is an attack that tricks an authenticated user's browser into submitting a request the user did not intend, such as changing their email or transferring funds. It abuses the fact that browsers automatically attach session cookies. The defenses are anti-CSRF tokens and SameSite cookie restrictions.
What CSRF is
Cross-site request forgery, tracked as CWE-352, is a vulnerability where a web application cannot tell whether a state-changing request was genuinely issued by the user or forged by a malicious site. Browsers automatically include a site's cookies with any request to that site, so if authentication relies only on an automatically sent session cookie, an attacker can craft a request that rides on the victim's existing session.
CSRF targets actions, not data theft: the attacker generally cannot read the response, but they can cause the application to perform an action the logged-in victim is authorized to do.
How the attack works
Say a bank processes transfers via POST /transfer with the parameters to and amount, authenticated solely by the session cookie. An attacker hosts a page containing an auto-submitting form that posts to the bank with to=attacker&amount=1000. When a victim who is logged into the bank visits the attacker's page, their browser submits the form and attaches the bank session cookie automatically. The bank sees a valid session and processes the transfer.
The victim never clicked anything on the bank site; a hidden form, an image tag pointing at a GET endpoint, or background JavaScript is enough. The attack works precisely because the request looks authentic to the server.
Real-world impact
- Account takeover by forcing an email or password change.
- Unauthorized financial transactions or purchases.
- Privilege or configuration changes in admin panels.
- Any state-changing action the victim is authorized to perform.
How to prevent it
Anti-CSRF tokens and SameSite cookies are complementary: tokens are the explicit control, while SameSite provides strong browser-level defense in depth.
- Use anti-CSRF tokens: a unique, unpredictable, per-session (or per-request) token that the server issues and must accompany every state-changing request. A cross-site attacker cannot read or guess it.
- Set session cookies to SameSite=Lax or SameSite=Strict so browsers do not send them on cross-site requests.
- Prefer the double-submit cookie or synchronizer-token patterns provided by your framework rather than rolling your own.
- Require re-authentication or verification for the most sensitive actions.
- Never use GET for state-changing operations.
Keep exploring
- CWE-352: Cross-Site Request ForgeryThe MITRE weakness entry CSRF maps to.
- What is cross-site scripting?The browser-side attack CSRF is often confused with.
- What is SSRF?A server-side request forgery with a similar-sounding name.
- Browse the CWE directoryExplore the full catalog of weakness types.
- What is broken access control?OWASP A01: acting outside your permissions.
- What is clickjacking?UI redress attacks via invisible frames.
Frequently asked questions
- What is CSRF in simple terms?
- It is an attack that makes your browser quietly send a request to a site you are logged into, using your existing session, so the site performs an action you never intended.
- How is CSRF different from XSS?
- XSS runs the attacker's script inside the trusted site and can read data. CSRF cannot read responses; it only forces the victim's browser to send an authenticated request to perform an action.
- How do SameSite cookies stop CSRF?
- SameSite=Lax or Strict tells the browser not to attach the session cookie to requests originating from other sites, so the forged cross-site request arrives without valid authentication.
- Which CWE covers CSRF?
- Cross-site request forgery is CWE-352, Cross-Site Request Forgery.