XSRF (Cross-Site Request Forgery)

XSRF, also known as Cross-Site Request Forgery (sometimes abbreviated as CSRF), is a type of malicious exploit in which unauthorized commands are transmitted from a user that a web application trusts. Unlike Cross-Site Scripting (XSS), which exploits the trust a user has for a particular site, XSRF exploits the trust that a site has in a user's browser. It is considered one of the most prevalent and dangerous web application vulnerabilities.

What is XSRF in web security?

XSRF is a web security vulnerability that enables an attacker to trick an authenticated user into unknowingly submitting a request to a web application. Because the user is already authenticated (e.g., logged in), the web application processes the forged request as legitimate. This can lead to unauthorized actions such as changing an email address, transferring funds, modifying account settings, or making purchases — all without the user's knowledge or consent.

The attack typically works by embedding a malicious link, image tag, or hidden form in an email, website, or blog post. When the victim clicks the link or loads the page, the browser automatically includes the victim's valid session cookies with the request, making it appear authentic to the target application.

Why is XSRF a serious vulnerability?

XSRF is a serious vulnerability for several reasons:

• Invisible to the victim: The user may never realize an attack occurred, as the forged request executes silently in the background.
• Exploits authenticated sessions: The attack leverages the user's existing trust relationship with the application, bypassing standard authentication checks.
• Wide impact: Any state-changing operation — such as financial transactions, password changes, or data deletions — is potentially vulnerable.
• Difficult to detect: From the server's perspective, the request looks like a normal, legitimate action from the authenticated user.

Organizations such as the OWASP Foundation and NIST consistently rank XSRF among the most critical web application security risks.

How does XSRF work?

A typical XSRF attack follows these steps:

1. The victim authenticates with a web application (e.g., their online banking portal) and receives a session cookie.
2. The attacker crafts a malicious request targeting a specific action on the vulnerable application (e.g., a funds transfer).
3. The attacker delivers the malicious request to the victim via a link, hidden image, or auto-submitting form embedded in an email or a third-party website.
4. When the victim loads the page or clicks the link, their browser automatically sends the request to the target application, including the valid session cookies.
5. The application processes the request as if it were a legitimate action by the authenticated user.

Real-world examples

• Bank Transfer Forgery: An attacker sends a user a link disguised as an image. If the user is logged into their online banking, clicking the link or simply viewing the image could trigger a malicious request to transfer money from their account to the attacker's account. The browser automatically includes the user's session cookies, making the request appear genuine.
• Password Change: An attacker crafts a hidden form on a malicious website that, when loaded, sends a POST request to a legitimate social media site's password change endpoint. If the victim is logged into the social media site, their password could be changed to a value set by the attacker without any visible indication.

When was XSRF first identified?

XSRF as a class of vulnerability has been recognized since the early 2000s, with the concept emerging alongside the growing complexity of web applications and their reliance on cookie-based session management. The term gained widespread recognition as organizations like the OWASP Foundation began cataloging and categorizing web security threats. It was included in the OWASP Top Ten list and has remained a critical concern in web security ever since. The W3C (World Wide Web Consortium) and browser vendors have since introduced mechanisms — such as the SameSite cookie attribute — to help mitigate this class of attack at the platform level.

Which security measures protect against XSRF?

Several well-established techniques help protect web applications against XSRF attacks:

• Anti-CSRF tokens: The most widely recommended defense. The server generates a unique, unpredictable token for each user session or form submission, which must be included with every state-changing request. Since the attacker cannot predict or access this token, forged requests are rejected. This approach is detailed in the OWASP CSRF Prevention Cheat Sheet.
• SameSite cookie attribute: Modern browsers support the SameSite attribute for cookies, which restricts when cookies are sent with cross-site requests. Setting SameSite=Strict or SameSite=Lax significantly reduces the risk of XSRF. More details are available in the MDN Web Docs on SameSite Cookies.
• Double-submit cookies: The application sets a random value in both a cookie and a request parameter. On submission, the server verifies that both values match.
• Checking the Origin and Referer headers: The server can verify that requests originate from trusted sources by inspecting the Origin or Referer HTTP headers.
• Requiring re-authentication: For sensitive operations such as password changes or financial transactions, requiring the user to re-enter their password adds an additional layer of protection.
• Custom request headers: For AJAX-based applications, requiring custom headers (e.g., X-Requested-With) can help, since browsers enforce the same-origin policy on such headers and cross-origin requests with custom headers require CORS preflight approval.

The NIST Special Publication 800-53 also recommends implementing XSRF protections as part of a comprehensive information security framework. Combining multiple defense strategies provides the strongest protection against this pervasive vulnerability.