Problem Framing
Cross-Site Request Forgery (CSRF), also known as XSRF, is a type of web security vulnerability that exploits the trust a web application has in a user's browser [1][2][3][4]. Attackers leverage this trust to trick an authenticated user's browser into submitting unintended, malicious requests to a trusted web application on their behalf [5][6][7][3]. The core of the vulnerability lies in the browser's default behavior of automatically attaching session cookies to requests made to a specific domain, regardless of the origin of the request [5][8][1]. This means that a request originating from an attacker-controlled site can appear legitimate to the target server if it carries the user's valid session cookie [5][4].
CSRF attacks are particularly effective against state-changing operations, such as updating user profiles, changing passwords, making purchases, or transferring funds [5][7][4]. The impact can range from minor inconveniences, like altering user preferences, to critical security breaches, including account takeover and complete system compromise, especially if the authenticated user has administrative privileges [9][6][7][10]. While HTTPS protects data in transit, it does not prevent CSRF, as it doesn't validate the intent of the request [5]. Similarly, relying solely on a Referrer header check is insufficient, as these headers can be absent or manipulated [5].
Core Mechanics
At its heart, a CSRF attack hinges on three fundamental conditions that must all be met for exploitation [5][11][12][13]:
1. A State-Changing Action: The target web application must have an endpoint or function that performs a state-changing operation. This means the action must modify data or have a side effect on the server. Attacks targeting read-only operations are generally not considered CSRF, as the attacker cannot intercept the response [7][4]. 2. Cookie-Based Session Management: The application must rely solely on session cookies (or similar automatically submitted credentials like HTTP Basic authentication) to authenticate and authorize requests for these state-changing actions. If requests are authenticated via custom headers (e.g., Authorization: Bearer ) that browsers do not automatically include in cross-site requests, CSRF is generally not possible [5][11][3][12]. 3. Predictable Request Parameters: The parameters required to perform the state-changing action must be predictable or guessable by the attacker. If an attacker cannot determine or guess necessary parameters (e.g., the current password for a password change), they cannot successfully forge the request, even with a valid session cookie [5][11][12].
The typical attack flow involves an attacker crafting a malicious request, often embedded in an HTML form, image tag, or script, hosted on a site they control [1][4][14][15]. When a logged-in victim visits this malicious page, their browser automatically sends the forged request, along with their session cookie, to the vulnerable application [5][6]. The application, trusting the session cookie, processes the request as if it were legitimate, executing the attacker's desired action [5][4].
A critical aspect is that the browser's Same-Origin Policy (SOP) generally prevents JavaScript from reading responses from cross-origin requests [16][17]. This limits CSRF's impact to state changes; attackers typically cannot directly read sensitive data returned by the forged request [4]. However, this does not prevent them from causing state changes or indirectly exfiltrating data if coupled with other vulnerabilities like XSS [18][19].
Notable Techniques
CSRF attacks manifest in various forms, exploiting different aspects of web application design and browser behavior. Some notable techniques include:
GET-Based CSRF
This is one of the simplest CSRF vectors. If a state-changing action is executed via a GET request, an attacker can embed this request within an HTML tag that the browser automatically fetches, such as an