1

Note: This question is not the same as the linked possible duplicate. That question asks how checking the origin/referer header protects against CSRF. This questions is asking how to implement the specific details.

I see a lot of places that to protect against CSRF for a REST API, you should check the referer and origin headers. However, no one seems to explain the details of that. Is just checking that the host is the same sufficient? Should the scheme also be checked?

Improve this question
3

2 Answers 2

Reset to default
1

Not sure I agree with the premise that checking referer and origin headers is the best defence. In a few corner cases both of these headers will be missing. In these cases the only safe option is to block the request, which could break functionality for a few legitimate users.

If this is still the path you want to take, OWASP has a lot of good info on the technicalities:

  • Start with the origin header, and if it is missing use the referer header.
  • Again, if none of these are present, you must block.
  • Comparing URL:s might seem simple, but it is actually a very tricky thing to do. Make sure your comparison is sound, and e.g. that good.com.evil.com does not pass as good.com. That is just an example, I am sure there are more pitfalls out there. Preferably you should use a good well tested library for this task.
  • It's probably good to check that the scheme is either http:// or https://. Not sure if there are any attacks that can be used if this check is not done, but god knows what clever tricks there are out there with data URI:s or what not.

If you want other options, consider the classics such as anti-CSRF tokens or double submit cookies. Or for an API, just using a bearer token in the authentication header does the trick.

Improve this answer
1
  • So it's not that these alone are the best defense, but that they are part of it. I will use these in combination with a CSRF token.
    – srchulo
    Aug 8, 2018 at 2:16
0

For details on how the headers are meant to protect against CSRF see How does sending referrer HTTP headers protect against CSRF attacks?

The key takeaway is that they are a mechanism to allow trustworthy clients to protect their users against malicious websites. They could easily be forged by a malicious client.

As for the host header which you ask about, this can potentially be rewritten by reverse-proxies etc along the way (hence special forwarding headers exist to capture this, see https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Forwarded-Host). By explicity using header(s) designed for this purpose you reduce the chances of them being rewritten (any decent intermediate software should not touch these) and your server sending incorrect response to the client.

Improve this answer

You must log in to answer this question.

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