People's Newsroom


A Cross-Site Request Forgery (CSRF) attack enables an attacker to forge requests to the target application from a legitimate user’s browser. A vulnerable application handles these forged requests the same way as legitimate requests from the victim. Successful CSRF attacks can trigger many actions in vulnerable applications, such as modifying account settings or stealing money through an online banking system. CSRF is prevalent in modern Websites and is ranked in both the OWASP Top 10 project and the CWE/SANS Top 25 Most Dangerous Programming Errors. Both small and large scale projects are affected, with for example CSRF vulnerabilities in online banking systems, Gmail, and eBay.


The goal of a CSRF attack is to forge a request from a victim’s browser to the target application, triggering state-changing effects in the target application. Examples of such state-changing effects are modifying account settings or adding items to a shopping cart. For a CSRF attack to succeed, it is essential that the user is already authenticated to the target application. From the application’s point of view, the forged request has the same structure as a legitimate request and is therefore indistinguishable from a legitimate request. Tricking the victim’s browser into making a request to the target application is a straightforward task. Browsers frequently issue requests to numerous unrelated sites, for instance when loading external resources such as images, stylesheets, or a document to load in a frame, but also when submitting form data to a cross-origin URI. An attacker can easily include code that triggers a request to the target application in his own Web site or a site he controls.

Alternatively, he can inject malicious HTML or JavaScript code in an unrelated but legitimate site, for example by posting code in the comments section of a legitimate forum. These two attack vectors respectively require the capabilities of a Web attacker and forum poster. The first list shows the code that uses a hidden image to trigger a forged request, and the Second list shows a cross-origin form submission.

A CSRF attack can only be successful if the forged request happens within a previously authenticated session between the victim’s browser and the target application.

Unfortunately, the design of current session management mechanisms in the browser attaches session information to any outgoing request, fostering the prevalence of CSRF attacks. For example, the browser attaches the relevant cookies for the domain, scheme, and path to each outgoing request, both for requests internal to the application and cross-site or cross-application requests. Additionally, many applications prefer long-living sessions, sticking around as long as the browser remains open, regardless of whether an application is currently active in a browser tab. Essentially, this means that if a user had an authenticated session with the target application in the lifetime of the browser, it is likely that forged requests within this authenticated session can be made.

A Login CSRF attack is a variation of a CSRF attack, where the attacker forges a request to authenticate the victim with an attacker-chosen account. Essentially, the attacker submits a login form from within the user’s browser, using the credentials of the attacker. When the user unknowingly uses the targeted application, any entered information is associated with the attacker chosen account, and can potentially leak to the attacker. A common example is a search engine keeping history for authenticated users. Next to traditional login CSRF attacks that forge a submission of the target application’s authentication form, login CSRF attacks can also target applications using third-party authentication providers such as Google single sign-on, Facebook authentication, or OpenID. These authentication providers provide the target application with an assertion, containing the necessary info to confirm a successful authentication, as well as the user’s identity. Using a login CSRF attack, an attacker can submit his own assertion to the target application from the victim’s browser, effectively establishing an authenticated session tied to the attacker’s credentials.

In essence, the problem of a CSRF attack is the lack of intent, leaving the server in the dark as to whether a request was made intentionally by the end-user or legitimate application code, or was forged by an attacker. The fact that browsers handle same-origin and cross-origin requests identically, and Web applications now heavily depend on this behavior, enables CSRF attacks and hampers effective countermeasures.

Mitigation Techniques

During the early years of CSRF, several simple mitigation techniques have been proposed but proven ineffective at protecting against CSRF attacks. One suggestion is to only carry out state-changing operations using POST requests, as actually mandated by the HTTP specification, assuming that forging POST requests is not feasible. Unfortunately, this is not the case, rendering this advice useless in protecting against CSRF. A second mitigation technique enforces referrer checking at the server-side. State-changing requests should only be accepted by the receiving application if the value of the Referer header,2 which denotes the sending origin, contains a trusted site, and is rejected otherwise. Referrer checking would effectively mitigate CSRF attacks, but unfortunately, the presence of the Referer header in the request headers is unreliable. The Referer header is often missing due to privacy concerns, since it tells the target application which resource at which URI triggered the request. Similarly, browsers do not add the header when an HTTPS resource, which is considered sensitive, refers to an HTTP resource. Additionally, browser settings, corporate proxies, privacy proxies or add-ons, and referrer-anonymizing services enable the stripping of automatically added Referer headers.

As an improvement to the Referer header, the Origin header provides the server with information about the origin of a request, without the strong privacy-invasive nature of the Referer header. Unfortunately, the specification only states that the Origin header may be added, but does not require user agents to do so, potentially causing the same problems as with the Referer header. The Origin header, however, is mandatory when using Cross-Origin Resource Sharing (CORS), an API that enables the sharing of resources across origins. An alternative, more effective countermeasure is token-based approaches, for example in a hidden field of a form. A token-based approach adds a unique token to the code triggering state-changing operations. When the browser submits the request leading to the action, the token is included automatically and verified by the server. Token-based approaches prevent the attacker from including a valid token in his payload, causing the request to be rejected.

The key to the success of this mitigation technique is keeping the token for action out of the attacker’s reach. This is achieved by embedding the tokens in the application’s page, where they are protected by the Same-Origin Policy, preventing theft by an attacker-controlled context, loaded in the same browser. Essential to a token-based approach is the security of the token. A token should be a hard-to-guess value, and should only be valid for a specific user. This typically requires storing the token in the user’s session object at the server-side, which may have a performance impact on the server. Further research on token-based approaches, which often struggle with Web 2.0 applications, has yielded several improvements over traditional tokens, to enable complex client-side scripting and cross-origin requests between cooperating sites. jCSRF, a server-side proxy solution, transparently adds security tokens to client-side resources and verifies the validity of incoming requests.

Alternatively, double-submit techniques embed a nonce in two different locations, for example in a cookie and as a hidden form field, allowing the server to compare both values, without keeping track of state. Since the attacker cannot manipulate both tokens, he is unable to forge valid requests. Another approach at the level of the application’s architecture is based on the observation that the cross-origin accessibility of Web application resources allows the attacker to target any resource by making a request from a different origin. Several techniques propose to mitigate CSRF by restricting the set of entry points to CSRF-protected resources, thus eliminating a CSRF attack on a sensitive resource. These entry points can be enforced purely at the server-side, or in combination with a browser-based mechanism. Recently, the concept of entry points gained traction with browser vendors and is being integrated as a core feature.

Another effective mitigation of CSRF attacks involves explicit user approval of state-changing operations. By requiring additional, unforgeable user interaction, the attacker is unable to complete the CSRF attack in the background. Examples are explicit re-authentication for sensitive operations, or the use of an out-of-band device to generate security tokens, as employed by many European online banking systems. Finally, client-side solutions have emerged to protect legacy applications, which are no longer updated, or where developers do not know or care about CSRF vulnerabilities, leaving users vulnerable in the end. These client-side solutions detect potentially dangerous requests and either block them or strip them from implicit authentication credentials, such as cookies. Examples are RequestRodeo, the first client-side mitigation technique in the form of a proxy, followed by browser add-ons CsFire, RequestPolicy, DeRef, and NoScript ABE. While these clientside solutions successfully prevent CSRF attacks, their main challenge is keeping the delicate balance between security and usability, which comes from the need to be compatible with all possible sites a user visits.


Current practices for mitigating CSRF attacks are focused on token-based approaches, either custom-built for the application, or deployed as part of a Web framework, such as Ruby on Rails, CodeIgniter, and several others. Alternatively, server-side libraries or APIs offer CSRF protection as well, such as the community-supported OWASP ESAPI API and CSRFGuard. Sites being built using a content management system (CMS) – instead of being built from scratch – can benefit from built-in CSRF support as well. For example, Drupal, Django, and WordPress offer token-based CSRF protection, with Drupal even extending its support to optional customized modules. Applications using the OAuth protocol for authentication are vulnerable to login CSRF attacks, as shown by a formal analysis of Web site authentication flows, which has dubbed this problem as social login CSRF. OAuth is a protocol enabling third-party clients limited access to an API, such as used in Facebook authentication. The OAuth specification recommends using a generated nonce, strongly bound to the user’s session, which would prevent a social login CSRF attack, if followed by the implementations of the protocol.

Back to top button