
Cross-site request forgery
It is hard to tell when the first CSRF attacks occurred, but we can in some cases trace them back as early as 2001. Even so, CSRF exploits did not start to get well-documented until 2007. Some of the notable companies targeted with CSRF attacks include, but are in no way limited to, Korean eBay, a prominent Mexican bank, YouTube, Netflix, and the computer security company McAfee.
What can you do to avoid such exploits? Teach your developers how to prevent cross-site request forgery with the help of Avatao’s secure coding training platform!
What is Cross-site request forgery (CSRF)?
Cross-Site Request Forgery is a well-known vulnerability in the IT security world. In a nutshell, an attacker tricks the victim into performing actions on a website which the user does not intend to do. In other words, the attacker sends unauthorized commands in the name of the victim to the targeted webpage.
While “Cross-Site” may sound familiar from the Cross-Site Scripting vulnerability, we should not confuse the two. CSRF attacks exploit the trust that a webpage has in a victim’s browser, whereas XSS exploits the trust the victim has for the webpage.
What are the possible consequences of CSRF?
An experienced attacker can easily make the victim execute an unintended action. These actions can be things like changing passwords, e-mail addresses, and usernames, or even more serious actions such as deleting profiles or transferring large amounts of money. In the worst case scenario, the attacker can gain access to a victim’s account and use it like his own.
CSRF in practice
The attacker crafts web requests to a website that the victim has privileged access to. This web request can be crafted to include URL parameters, cookies, and other data that appear normal to the web server processing the request.
The three main conditions needed for a CSRF attack are as follows:
- Utilizing cookie sessions: Nowadays, most applications rely solely on session cookies to identify the user who has made the requests. So the only way to perform a CRSF attack and validate user requests is to use the sessions.
- Simple request parameters: If the request contains parameters with complex values that are unpredictable, the attack is highly unfeasible. The best thing is when the request does not contain any parameters.
- Significant action: There are a variety of reasons to execute this type of attack. The main motivations are often transferring money or getting access to a user’s data. If the information has a high value and is worth the effort to obtain it, it is reasonable to be wary of CSRF attacks.
Preventing Cross-site request forgery
What can users do to prevent CSRF?
Signing out of accounts and avoiding the “Remember me” option can reduce the risk of CSRF attacks. Additionally, users should treat links in emails and any other insecure links with great care.
What can developers do to prevent CSRF?
- Use a specific CSRF Token in every request from the user
- Request authentication data from the user
- Limit the Cookie Sessions lifetime
- Check the HTTP Referer and HTTP Origin headers

Get started with secure coding training today
