原文链接：http://www.sjoerdlangkemper.nl/2019/02/27/prevent-csrf-with-the-origin-http-request-header/
HTTP请求中的Origin请求头表示请求的来源，可以对防御跨站请求伪造攻击起到作用。
跨站请求
有些跨站请求是正常的，比如从另一个域调用图片等。但你一定不想将包含一些信息的认证请求呈现给另一个域，也就是CSRF。确定哪个页面发出请求对于积极防御CSRF攻击是很有用的，如果一个站点能确定请求来自哪里，它就能过滤请求。Referer头会包含这个信息但它是不可靠的，Origin头才是将这个信息添加到请求的可靠方式。
Referer请求头
Referer头是一个较古老的请求头，包含了用户来源URL，当你点击一个链接时，当前页面的URL会被发送到这个链接。也就是说，这可以用于确定用户来自哪里，从而帮助我们阻止跨站请求。然而Referer头存在两个问题。
第一，Referer头不够详尽。哪个请求应该发送Referer，甚至究竟是否该发送这个请求头都未被清楚说明。即使大多数浏览器确实发送了这个请求头，它们也并没有这样做的依据。
第二，Referer请求头会泄露整个URL给别的域。如果URL包含一些session token或其他敏感数据，用户点击链接发送的Referer头将会将这些数据发送出去。这也是为什么许多反病毒方案会将HTTP请求中的Referer请求头直接去掉，以防止URL泄露敏感数据，因此我们并不能依赖Referer头。
Origin请求头
Origin请求头只包含URL的格式、主机名和端口，也就避免了URL参数泄露给其他主机，虽然仍旧可以看出请求的来源。请求头看起来大概像这样：
Origin: https://www.sjoerdlangkemper.nl
根据说明文档，HTTP请求可以包含多个Origin头，虽然我还没见过浏览器这样使用。还存在一个特殊的null值来表明这个来源是不可靠的。
null值
如果文本不存在清晰的源，或请求根本不可信，不需要考虑源，null就可以用来表示。
在一些情况下，字符串”null”会替代来源信息被发出，这样做是为了表明请求是不可信的，即使它是同源请求。某些请求在变化的触发条件下[…]未必总有用，而且可能并不可信，即使来自同一个源。
浏览器会使用null Origin，比如iframe + data URL的例子：
<iframe src="data:text/html,<form method="POST"...
现代浏览器认为Data URLs是唯一不透明的源而不是继承包含页面的源。这说明data URL的源从不可靠，而null Origin就是被用来表明这一点的。
浏览器差异
即使Origin的文档描述了这个请求头并且指明了一些用法，它也并没有定义好什么时候包含Origin头或Origin的期望值。Chrome和Firefox都在JavaScript POST请求中包含了Origin头，这些请求的行为和其他都不相同。Origin请求头被包含在：
- Chrome的所有POST表单，Firefox的则没有
- Firefox的所有JavaScript Fetch请求，Chrome中不包含HEAD和GET
- 跨域重定向，Firefox使用来源域作为Origin而Chrome使用null Origin
用这个样例页面观察你的浏览器行为。
这些差异使得目前origin请求头的使用比较有限，不能依赖Origin头呈现在特定种类请求中，也就限制了防御的深度：在它呈现时检测它，但不要依赖它。
结论
检测Origin请求头是一个良好的额外防御跨站请求伪造及相关攻击的方式，虽然它已经被应用在浏览器中，但他的行为定义还没有完善到能依赖Origin头在特定请求中呈现。