扩展@Sjoerd 和@lindon 的答案。

Originvs Referervs CSRF 令牌

最有可能的是，OWASP 建议也使用 CSRF 令牌的原因是，在提出此建议时 - 很大一部分浏览器还不支持Origin标头。现在已经不是这样了，但人是黑猩猩。

为了保护隐私，任何浏览器请求都可以决定省略Referer标头。所以最好只检查Origin标题。（如果您想允许用户保护他们的隐私）

在某些情况下，Origin标头为空。请注意，所有这些请求都是 GET 请求，这意味着它们不应该有任何副作用。

只要确保使用浏览器发送请求的恶意网站无法读取响应，就可以了。这可以使用适当的 CORS 标头来确保。（不要使用Access-Control-Allow-Origin: *！）

为防止“点击劫持”，请设置 header X-Frame-Options: DENY。这将告诉您的浏览器不允许在 iframe 中显示您网站的任何部分。

“新”方法

设置 Cookie 属性SameSite=lax或SameSite=strict将防止 CSRF 攻击。这是一个相当新的功能，不能单独使用，原因很简单，不是所有常见的浏览器都支持它。您可以在此处跟踪支持。

当浏览器这样做时，人们可能仍会建议检查 Origin/Referer/CSRF 令牌。如果他们这样做了——没有给出充分的理由，很可能是因为他们是黑猩猩。

是的，这是安全的。

但是，referer 标头并不完全是强制性的，因此可能有浏览器或代理不发送referer 标头。这意味着这些客户无法访问您的网站。

通过引入引荐来源网址策略，可以从伪造请求中删除引荐来源网址标头。因此，为了防止 CSRF，有必要阻止任何缺少引用者（和来源）标头的请求。

编辑：本文有一些数字说明客户的哪些部分省略了引用标头。

OWASP建议 除了检查来源和引用者之外，还要检查 CSRF 令牌。

接受的答案已经涵盖了大部分内容。但是，即使启用了 SameSite=strict，您仍然需要 CSRF 令牌的特殊情况。

例如，网站 A 允许用户从他们想要的任何地方发布内容和嵌入图像源。然后，恶意用户可以插入带有src=website-a.com/remove/something. 该图片在网站A中展示，因此，当普通用户浏览该图片时，从该图片发起的请求与网站A是同源的。

一个问题是，从图像发起的请求是 GET 请求，大多数操作 API 都是 POST。然而，恶意用户通常可以将请求从 POST 转换为 GET 并且服务器仍然接受它，这使得 CSRF 攻击成为可能。