Cross-site (CSRF) is one of the vulnerabilities on OWASP‘s 10 list and allows attackers to make requests on behalf on the user. is a non-profit organization with the goal of improving the security of software and the internet. We cover their list of the ten most common vulnerabilities one by one in our OWASP Top 10 blog series.


Cross-Site Request Forgery, also called CSRF, is when an attacker is able to make requests on behalf of a user. The attacker often takes advantage of the fact that the user is already authenticated, but with some types of this attack (e.g. Login CSRF) that is not needed.

This is just about sending requests. As the attacker cannot read the response, it is not of any use to force the victim to retrieve data. CSRF attacks therefore only target state-changing requests.


In 2010, OWASP ranked this vulnerability as fifth on their list of the most important vulnerabilities. When they re-did that list in 2013, it had dropped to the eighth place and its prevalence went from widespread to common.

The decrease in importance has much to do with frameworks becoming better at automatically protecting against this and people being more aware. With that said, we still see this vulnerability a lot, and a quick search at Hackerone shows that it is still found at big companies as well.

A new place where CSRF has begun to appear is in API calls. It has become more popular to do sensitive requests over different APIs instead of regular requests, and developers seem to forget a token is needed there as well.

Potential impact of Cross-site Request Forgery

Assuming the target is a normal user, a successful attack could lead to any state-changing request such as changing credentials, transferring funds, modifying settings, etc. being executed on the user’s behalf. The same applies if an admin is the target, but the request would then be executed with admin privileges. In the latter case it could potentially lead to a full system takeover.


The user would need to click a link or visit a page with the link embedded, the latter could for example be an img tag. That can be done by hacking a site the attacker knows the user will visit, MITMing the user, send the user an email to trick them to click the link, etc.

It is sometimes possible to store the CSRF attack vector on the vulnerable site, which would make this more likely to be abused as it would be easier to spread. An example would be a forum where an attacker could include a picture and then choose the crafted CSRF link as source.

Well-known events

Less than three years ago some security researchers were able to identify that 300.000 home routers had been compromised. The DNS settings had been changed, giving the attacker control over every request sent from devices using the router. The attack method used varied, but for some of the routers they used CSRF vulnerabilities. By just visiting a webpage with the CSRF payload, all traffic from thereon could be controlled by the attackers.

How to discover Cross-site Request Forgery

Look for any link, form or API call that lacks a CSRF token or other protection.

There are also some common misconceptions about protection, look into that and see if the developer seems to have fallen for any of them. See the Remediation section for examples of what is not enough.

How Detectify can help

We provide a quick and easy way to check whether your site passes or fails OWASP Top 10 tests. Detectify is a web security scanner that performs fully automated tests to identify security issues on your website. It tests your website for over 700 vulnerabilities, including OWASP Top 10, and can be used on both staging and production environments. Sign up for a free trial to find out if you are vulnerable » 

Example of vulnerable

Let’s assume there is a bank interface that looks something like this:

<form action=”send.php” method=”get”>
    <input name=”amount” placeholder=”Amount”>
    <input name=”account” placeholder=”Destination”>
    <input type=”submit” value=”Transfer”>

The request for sending 10 USD to 1234 would look like this:

As there is no token or any other protection mechanism implemented an attacker can just send that link to a logged-in user, and when the user clicks the link 10 USD would be transferred to the account 1234.

An attacker could buy an advertisement on a popular website in the same as country the bank, and include the snippet of code below. The potential damage should be obvious.

<img src=””></img>


For every request that is considered important or sensitive, an unpredictable token should be included. These must at a minimum be unique per user session, but could be randomly generated for each request.

Another solution that is often used with the most sensitive forms is re-authentication, meaning that the user needs to enter the password twice. A common application of this are change-password fields, but the same method can be implemented with other forms as well with the same result. However, the user experience would be a bit annoying having to enter the password all the time, so it should be used sparingly.

Many frameworks have got built-in protection mechanism against these attacks today. Look into this and see if it can be enabled as it is not always enabled by default.

A misconception that is way too common seems to be that a captcha somehow protects against CSRF. That is not necessarily true (it can be depending on the implementation), but a lot of security guides say so. Even the OWASP article on the subject seems to recommend this. The reason this is not enough to prevent CSRF is basically that an attacker can solve a captcha themselves and then send the challenge together with the response with the CSR request. Read more about that method here.

Another common misconception is that it is enough to only accept POST requests as the attacker then cannot create a malicious link, but this is false. With just a few lines of JavaScript the attacker would be able to bypass this.

Remember that IP addresses, session cookies, local storage, etc., are always included in requests, even the forged ones, so checking such information is of no use for protecting against CSRF. An XSS vulnerability would bypass most of the CSRF protections, with re-authentication being the exception.

Watch the video:

If any of this is confusing, or you just want to discuss a solution or implementation, do not hesitate to contact our support at [email protected].

Read more

Top 10 2013: Cross-site Request Forgery (CSRF)
Cross-site Request Forgery (CSRF) Prevention Cheat Sheet
Cross-site Request Forgery

Login CSRF

Source link


Please enter your comment!
Please enter your name here