Is it possible to prevent CSRF by checking the Origin and Referer headers? Is this adequate, provided that requests with neither are blocked?


Expanding on the answers of @Sjoerd and @lindon.

Origin vs Referer vs CSRF token

Most likely, the reason OWASP recommends also using a CSRF token, is that at the time when this recommendation was made - a significant portion of browsers did not yet support the Origin header. This is no longer the case, but people are chimpanzees.

In order to preserve privacy, any browser request can decide to omit the Referer header. So it is probably best to only check the Origin header. (In case you want to allow for users to preserve their privacy)

The Origin header is null in some cases. Note that all of these requests are GET requests, which means they should not have any side effects.

As long as you make sure the malicious website sending the requests with your browser cannot read the responses, you should be fine. This can be ensured using proper CORS headers. (Do not use Access-Control-Allow-Origin: *!)

To prevent "click-jacking", set the header X-Frame-Options: DENY. This will tell your browser that it is not allowed to display any part of your website in an iframe.

The "new" approach

Setting Cookie properties SameSite=lax or SameSite=strict will prevent CSRF attacks. This is a quite new feature though, and cannot be used alone, simply for the reason that not all common browsers support it yet. You can track support HERE.

When the browsers do, people will likely still recommend checking Origin/Referer/CSRF tokens. If they do - without giving a good reason, it is likely because they are chimps.

| improve this answer | |
  • 2
    according to MDN, Edge doesn't send the Origin header with POST requests – Razor Mar 24 '19 at 17:42
  • @Razor: That is a very good point! Edge 16-18 does support the SameSite cookie property. Those using Edge 12-15 (0.13% globally at the time of this comment) would be vulnerable to CSRF attacks for websites not using tokens. – Tobias Bergkvist Mar 25 '19 at 18:56
  • It also appears that this is an opt-in feature in Firefox, and is available only since version 59. Source. However, this is addressable by just disallowing Origin-less requests altogether, and using JavaScript for form submission. Not optimal, but good enough. – Alec Mev Oct 24 '19 at 13:38
  • Beware that Origin header is not always sent for requests on the same origin. – Alireza Jun 13 at 11:05

Yes, this is secure.

However, the referer header is not exactly mandatory, so there may be browsers or proxies than don't send a referer header. This would mean that these clients can't access your web site.

With the introduction of referrer policy it is possible to remove the referer header from a forged request. So to protect against CSRF it is necessary to block any requests that are missing a referer (and origin) header.

Edit: This paper has some numbers on what portion of clients omit a referer header.

| improve this answer | |
  • What about referer header and HTTPS? If site is hosted on HTTP and CSRF is initiated from HTTPS site, there will be no referer header to check. – Marko Vodopija Apr 25 '17 at 9:34
  • If site is hosted on HTTP then you are insecure be definition. – Demi Apr 27 '17 at 16:11
  • 2
    I think one could construct a case where even a non-zero Referer should not be trusted: If the target site T contains a link to some external site X (or embeds a resource like an image from this site, e.g. an avatar) and an attacker can make modifications to site X then the request from site T to site X (containing a Referer from T) could be answered with a HTTP redirect back to site T but with some malicious action in the URL. In this case T sees a request with a Referer of T and trusts it, even though the target URL at T is controlled by X. – Steffen Ullrich Oct 23 '17 at 12:43
  • @SteffenUllrich That is an excellent point! Of course, GET requests should be idempotent so that it doesn't matter if they're "forged" because they don't change any state, but people mess that one up all the time (including expecting POST requests but allowing GETs to that endpoint as well). – CBHacking Nov 8 '18 at 20:37
  • Why checking Origin``header alone is not enough? And also, by checking these headers, do you mean validating that the requests Origin` header matches the ones you whitelisted in the application? – eddyP23 Nov 12 '18 at 11:11

OWASP recommends checking a CSRF token in addition to checking the origin and referer.

| improve this answer | |
  • 11
    I don't consider this an answer since the question was not if further things are recommended but if Referer and Origin are enough. If you feel that these are not enough please explain why instead of linking to a resource which does not explain this either. The only reason CSRF tokens are recommended additionally in the document your reference are "to really make sure" without further explanation. – Steffen Ullrich Apr 25 '17 at 4:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.