31

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

1

4 Answers 4

33

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.

9
  • 2
    according to MDN, Edge doesn't send the Origin header with POST requests
    – Razor
    Mar 24, 2019 at 17:42
  • 1
    @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. Mar 25, 2019 at 18:56
  • 1
    Beware that Origin header is not always sent for requests on the same origin.
    – Alireza
    Jun 13, 2020 at 11:05
  • 1
    Consider also an attack where the request is actually sent from the same site, by user-generated content. Not technically "cross-site" request forgery I guess, but still request forgery that CSRF tokens can protect against (since you can't create a crafted URL), I think.
    – nog642
    Jun 30, 2021 at 4:56
  • 1
    @MuhammadUmer, the image will be displayed, but Same Origin Policy will prevent javascripts from reading the image contents. Only the image width and height will be available.
    – eel ghEEz
    Mar 26, 2022 at 4:06
12

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.

5
  • 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. Apr 25, 2017 at 9:34
  • If site is hosted on HTTP then you are insecure be definition.
    – Demi
    Apr 27, 2017 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. Oct 23, 2017 at 12:43
  • 1
    @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, 2018 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, 2018 at 11:11
2

The accepted answer covered most of the things already. However, there is special case where you still need CSRF token even if you SameSite=strict is enable.

For example, website A lets users post contents and embed image source from wherever they want. Then, malicious user can insert an image with src=website-a.com/remove/something. This image is shown in website A, therefore, when normal users browse to this image, request initiated from this image is same origin with website A.

One problem is, request initiated from image a GET request, most action APIs are POST. However, Malicious user can often convert request from POST to GET and server still accept it, which makes CSRF attack possible.

2
  • In this case do you need a CSRF token or do you need to ensure that GET requests don't change state? Seems like either would suffice and that the latter might be preferable, especially since frameworks like ASP.NET Core don't validate the antiforgery token by default on GET requests. Mar 4, 2023 at 11:52
  • 2
    @ChaseMedallion, we need to ensure GET requests don't change state. Because if they do, there are more problems than just CSRF. For example, rate-limiting protection usually works with POST requests only. If attacker can change state with GET requests. They can bypass rate-limit and spam servers with heavy loads. Mar 17, 2023 at 2:55
0

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

1
  • 15
    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. Apr 25, 2017 at 4:37

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .