Is checking the referrer enough to protect against a CSRF attack?

Question

Is checking the referrer enough to protect against a cross site request forgery attack? I know the referrer can be spoofed, but is there any way for the attacker to do that

Answer 1

Follow the norm: use tokens.

Checking the referrer actually does nothing, because the request is coming from that page anyway! The problem you are trying to prevent is the page being requested without the user doing anything; not the page being hit itself.

Tokens are the way to protect against this. You generate one, store it in the session, and write it to the HTML, then, upon posting, you check the one you receive, and see if it matches the one you expect. If it doesn't, you fail. Either way, you generate a new token afterwards.

It may also be relevant to consider that this will mess people up if the have multiple pages; so you may like to make a different token per page.

Answer 2

The only correct answer is "Among other things, using the referrer won't work for users whose browsers (or corporate proxies) don't send referrers." That being said, that's highly uncommon nowadays. All the people saying that referrers can be faked are full of it. You cannot fake a referrer unless you have control over the other person's browser in some other way (XSS/Trojan/etc). If you require referrers for app use they are just as effective as CSRF Tokens. Just make sure you are making 100% sure that your check is correct (eg. if you are using regex make sure you check from the beginning "^" of the referrer).

Answer 3

Among other things, using the referrer won't work for users whose browsers (or corporate proxies) don't send referrers.

Answer 4

This is a 3 year old question with four different answers basically stating the same thing: Follow the norm, use tokens, don't try to use referer.

While tokens still is considered the most secure option, using the referer is often a lot easier, and is also pretty secure. Just be sure to look at all PUT/POST/PATCH/DELETE-requests and consider it an attack if a referer is missing or from the wrong domain. Really few (if any) proxies remove the referer for these kinds of requests.

See also the OWASP recommendation about checking the referer header as a CSRF protection:

Checking The Referer Header

Although it is trivial to spoof the referer header on your own browser, it is impossible to do so in a CSRF attack. Checking the referer is a commonly used method of preventing CSRF on embedded network devices because it does not require a per-user state. This makes a referer a useful method of CSRF prevention when memory is scarce.

However, checking the referer is considered to be a weaker from of CSRF protection. For example, open redirect vulnerabilities can be used to exploit GET-based requests that are protected with a referer check. It should be noted that GET requests should never incur a state change as this is a violation of the HTTP specification.

There are also common implementation mistakes with referer checks. For example if the CSRF attack originates from an HTTPS domain then the referer will be omitted. In this case the lack of a referer should be considered to be an attack when the request is performing a state change. Also note that the attacker has limited influence over the referer. For example, if the victim's domain is "site.com" then an attacker have the CSRF exploit originate from "site.com.attacker.com" which may fool a broken referer check implementation. XSS can be used to bypass a referer check.

Answer 5

no is not enough, it is very easy for the attacker to do that FOR the client, as you ask, all the attacker has to do is get the user to click in a link created by him, from that point, is game over

The attacker will copy the form used in the original site, and spoof the rest because now the code is on his own site, then submit that to the victim site

As you mention on the question, tokens are the norm when it comes to prevent CSRF