Is it worth checking the referrer?

Question

I have researching CSRF and one thing on the list, I feel is questionable. I am not sure if "checking the referrer" is worth doing or not.

Some articles I read, are saying something of this nature:

However, this is risky, as some corporate proxies strip the referrer from all HTTP requests as an anonymization feature. You would end up potentially blocking legitimate users.

Other articles I'm reading say you should do it and consider an empty referrer as an attack.

My website does deal with multiple corporations and if its true that a corporations proxy can omit the referrer then I find it being a problem then an actual benefit to the website.

Answer 1

I'd say that using, lack of, referrer as the sole indicator of an attack is likely to be troublesome as you can't be sure that all clients will send it as expected. In general using referrer as a protection against CSRF isn't considered a good idea as it can be spoofed under some circumstances.

If there were no other options then it might be worth using, but for CSRF there are better established mechanisms for protection (some info. here) such that in most cases the best approach is to use the framework's in-built protection mechanisms, unless you have a specific reason why those don't work in your use-case or are inadequate.

Answer 2

Usability

Yes, some people do not send referers. This may be for privacy reasons, or for security reasons (URLs should not contain sensitive data such as session ids, but that doesn't mean that they never do).

Security

If your website has an open redirect vulnerability, referer checks can be bypassed for GET requests. Of course, GET requests should not change state, but that doesn't mean that they never do.

Conclusion

To prevent CSRF, I would use an anti-CSRF token. It works, and it doesn't have the downsides of referer checking.

For the general benefits and drawbacks of checking the referer see this answer and for general information about CSRF prevention check out this OWASP guide.

Answer 3

The referrer may be used as an indication that some other website directly link to your content. You may want to trigger some restrictions (or simply log) when you encounter a referrer pointing to a different website than your own for bandwidth or copyright purposes.

However, you must not assume that every browser will send you a "referer" header. The RFC 7231 mentions that "not all requests contains it", while Wikipedia has got a nice paragraph concerning referrer hiding for privacy purposes. The same RFC section also deals with such practices, including when the "referer" header is removed by an intermediary as in the corporations you mentions:

Some intermediaries have been known to indiscriminately remove Referer header fields from outgoing requests. This has the unfortunate side effect of interfering with protection against CSRF attacks, which can be far more harmful to their users. Intermediaries and user agent extensions that wish to limit information disclosure in Referer ought to restrict their changes to specific edits, such as replacing internal domain names with pseudonyms or truncating the query and/or path components. An intermediary SHOULD NOT modify or delete the Referer header field when the field value shares the same scheme and host as the request target.

But as you can see, there is no obligation to keep the referrer: "SHOULD NOT" means that they can still remove it and stay RFC compliant.

Answer 4

There are several non-malicious reasons why an Referer header might be empty:

• the URL was accessed from a bookmark, from inside a mail or the URL was simply typed into the browser
• support for Referer was disabled in the browser or Referer got stripped by a firewall

Apart from that the Referer might be disabled by a noreferrer attribute in links, by using meta refresh tags and other methods. These methods might be used by an attacker but might be use for non-attack purposes too.

This means that you can only consider an empty Referer header as a sign of attack if you have enough control over the client that you can make sure that it will only access your application the way you have intended. This might be the case for a Web-GUI to administrate some local device but it is probably not possible to do with a globally available web application with lots of different clients and their middleboxes (firewall etc).

But you can still take an non-empty unexpected Referer as a sign of a possible attack and add another protection layer this way, additionally to CSRF tokens.