简单的说

• Origin并非所有浏览器都为同源请求发送标头。
• 当前流行浏览器中的错误意味着不会为 POST 请求发送 Origin 标头，这使得这种方法没有用处，因为状态更改请求应始终使用 POST 高于 GET。

这会在实现 CSRF 保护时产生复杂的逻辑。

那是：

Lack of Origin header = Old browser/bug OR
Lack of Origin header = Same Origin
Origin header matches domain = Same Origin
Origin header does not match = CSRF attack

如您所见，无法区分可能进行 CSRF 攻击的旧浏览器或有缺陷的浏览器和当前合法的浏览器请求。您可以添加浏览器检测，但随后逻辑变得更加混乱。复杂性往往会降低安全性。

当然，这可以在浏览器更新中进行修补。但是，您的应用程序将与旧版本的浏览器不兼容。

更简单的是生成一个令牌并将其与 cookie 机制之外的每个请求一起发送。

这主要是由于历史。自 2000 年代初，在 Origin 标头被发明之前，人们就已经意识到了 CSRF。“隐藏字段中的令牌”的概念为网站提供了一种立即修复漏洞的方法，而无需等待浏览器更新。虽然该机制有点混乱，但事实证明框架可以自动提供此功能，而无需应用程序开发人员提供很少的输入。值得注意的是，.Net 从一开始就将其包含在 EVENTVALIDATION/VIEWSTATE 中，而 .Net 应用程序存在 CSRF 缺陷的情况相对较少。

当 CSRF 刚被认真对待时，有人提议检查 Referer 标头来修复该漏洞。众所周知，Referer 标头很容易被欺骗，但这种想法并不像看起来那么愚蠢。当攻击者直接连接到 Web 服务器时，很容易欺骗 Referer 标头。然而，在 CSRF 攻击中，攻击者并没有进行直接连接；受害者的网络浏览器正在建立连接，攻击者无法轻易控制Referer标头。然而，这种方法仍然存在缺陷。旧版本的 Flash 允许攻击者在 CSRF 攻击场景中自由控制 Referer 标头。此外，一些用户出于隐私原因禁用了 Referer 标头，网站会将其误认为是 CSRF 攻击。

Origin 标头已被开发为Referer 标头的更安全的替代品。在许多方面，它是一个更简洁的 CSRF 解决方案，并且避免了管理令牌的开销。一些应用程序——尤其是单页应用程序——使用 Origin 标头作为唯一的 CSRF 保护并且是完全安全的。然而，这是例外而不是规则。同步器模式很容易理解，得到框架的广泛支持，并且没有已知的弱点。

编辑- Silverlightfox 通知我以下内容不正确。有关更多信息，请参阅他的答案。

最终，我认为 OWASP 的建议有点落后。在 2015 年，他们应该建议将 Origin 标头检查作为主要控制，将同步器模式作为传统替代方案。

任何浏览器缺陷，例如它允许在客户端设置 Origin 标头（在现代浏览器中极不可能）现在都会启用针对您的应用程序的 CSRF 攻击。

此外，来自https://security.stackexchange.com/a/74526/66075

您目前不能依赖 Origin 标头，因为它并未在所有正在使用的浏览器中实现。除此之外，并非在所有与 CSRF 相关的情况下都发送 Origin。

此外，从 SilverlightFox 对https://stackoverflow.com/a/24692474/4399898上类似问题的回答，

以前存在浏览器漏洞，例如 IE 5.5/6.0 中的漏洞，攻击者可以绕过同源策略并执行攻击。您通常可以期望这些一旦发现就会被修补，并且大多数浏览器会自动更新，这种风险将大部分得到缓解。

和

旧版本的 Flash 允许设置任意标头，这将使攻击者能够从受害者的机器发送带有欺骗性引用标头的请求，以执行攻击。