What Is Cross-Site Request Forgery (CSRF)?

Cross-Site Request Forgery (CSRF, sometimes pronounced “sea-surf”) is a web security vulnerability that tricks an authenticated user’s browser into sending an unwanted request to a web application the user is logged in to. Because the browser automatically includes the user’s session cookies with the request, the application treats the forged request as legitimate and performs the action, such as changing an email address, transferring funds, or updating settings, without the user’s knowledge or consent.

The elegance, and danger, of CSRF is that it exploits trust rather than a coding flaw in the traditional sense. The application trusts the user’s browser, and the attacker abuses that trust from a different site.

How CSRF Attacks Work

A CSRF attack depends on three conditions: the victim is authenticated to the target site, the target performs a state-changing action based on a predictable request, and the request relies only on automatically sent credentials like session cookies.

The attack unfolds simply. The victim logs in to a legitimate site, establishing a session. The attacker lures the victim to a malicious page, through a link, email, or ad, that silently contains a crafted request to the target site (an image tag, an auto-submitting form, or a background script). The victim’s browser sends that request to the target and, following normal browser behavior, attaches the victim’s session cookies. The target site sees a valid, authenticated request and executes the action. The victim may never realize anything happened.

Crucially, the attacker never sees the response or steals the session. CSRF is about causing actions, not reading data.

CSRF vs. XSS: What’s the Difference

The distinction comes down to which trust relationship is abused.

Cross-Site Request Forgery exploits the site’s trust in the user’s browser. The malicious code runs on the attacker’s site, and it leverages the fact that the browser will automatically authenticate requests to the target. The attacker can trigger actions but cannot read the response.

Cross-Site Scripting (XSS) exploits the user’s trust in the site. The attacker injects malicious script that runs within the legitimate site’s context, which lets them read data, steal session tokens, and do far more than blind actions. In short: CSRF makes the browser send a request the user did not intend, while XSS runs attacker code inside a site the user trusts. Notably, an XSS flaw can defeat many CSRF defenses, which is why XSS is generally considered the more severe of the two.

Real-World Impact of CSRF Attacks

The impact of CSRF depends entirely on what actions the target application allows an authenticated user to take. Documented and demonstrated CSRF issues have enabled attackers to change account email addresses and passwords (often leading to full account takeover), initiate money transfers on banking and payment platforms, modify security or privacy settings, add attacker-controlled users or rules, and alter configurations on home routers and IoT devices through their web interfaces. When CSRF targets an administrative account, a single forged request can compromise an entire application. Because the actions are performed with the victim’s own valid session, they can be difficult to distinguish from legitimate activity after the fact.

How to Prevent CSRF

Anti-CSRF Tokens

The primary defense is a synchronizer token: the server embeds a unique, unpredictable, per-session (or per-request) token in each form or state-changing request, and rejects any request lacking the correct token. Because an attacker on another site cannot read or guess this token, the forged request fails. Anti-CSRF tokens are the most widely recommended and effective mitigation, and most modern web frameworks provide them built in.

SameSite Cookies

The SameSite cookie attribute instructs browsers not to send cookies with cross-site requests. Setting session cookies to SameSite=Lax (the modern default in major browsers) or SameSite=Strict prevents the browser from automatically attaching credentials to requests originating from other sites, cutting off the mechanism CSRF depends on. It is a strong, low-effort defensive layer, best used alongside tokens rather than instead of them.

Re-Authentication for Sensitive Actions

For high-value operations, such as changing a password, transferring funds, or modifying security settings, requiring the user to re-enter credentials or confirm through a separate factor ensures a forged background request cannot complete the action silently.

Testing for CSRF Vulnerabilities

Testing focuses on state-changing requests. Testers examine whether sensitive actions rely solely on automatically sent cookies, attempt to replay or forge those requests from a different origin without a valid token, and verify that removing or altering the anti-CSRF token causes the request to be rejected. Requests that succeed without a valid, unpredictable token, and without other origin checks, indicate a CSRF weakness. Automated scanners and web security testing tools can flag candidate endpoints, but manual verification confirms genuine exploitability.

FAQ

What is the difference between CSRF and XSS?

CSRF exploits the site’s trust in the user’s browser to trigger unwanted actions, and cannot read responses. XSS exploits the user’s trust in the site by running malicious script in the site’s context, which can read data and steal sessions. XSS is generally the more severe.

What is the most effective defense against CSRF?

Anti-CSRF (synchronizer) tokens: unpredictable per-session tokens the server requires on state-changing requests. Combined with SameSite cookies, they neutralize the vast majority of CSRF attacks.

Can CSRF steal my data?

Not directly. CSRF causes actions on your behalf, such as changing settings or transferring funds, but the attacker cannot read the application’s responses. Data theft through a webpage is the domain of XSS.

Do SameSite cookies alone stop CSRF?

They are a strong layer and block the automatic cross-site sending of cookies, but they are best combined with anti-CSRF tokens for defense in depth rather than relied on as the only control.