Web Security Request Origin
Transcript from the "Request Origin" Lesson
>> Mike North: So another best practice is to validate the request origin. Modern browsers, they send the origin header. And you can try to alter it with your client side code, and it'll sort of appear that you can. But your changes won't have stuck. By the time the request goes out, that origin header will be back to what it was in the beginning.
[00:00:21] It's one of these things we can't tamper with. So all of the evergreen browsers currently send origin, IE 11 in some cases for some cross origin cases, it does not. Whenever the origin header is not there, there's almost always a referer header. Funny side note here, it's misspelled.
[00:00:40] That is a legitimate misspelling. The standard has the misspelling error and we must respect it forever. This quote is from an email thread where the person who added this to the HTTP spec has petitioned the Oxford English Dictionary to change its spelling of referer to his misspelling, because the argument is it's used much, much more often with this spelling, compared to the correct one.
[00:01:11] When you're behind a proxy, you can still usually look at the Host and X-Forwarded-Host headers to see where that originally came from. If you're using Heroku, for example, you are always behind Squid, which is a proxy. And you will always have X-Forwarded-Host available to you, so that you can make sense of which origin did this really come from?
[00:01:32] You don't care about where's that proxy sitting. You probably know a lot about that proxy cuz it's part of your infrastructure.