大多数 CSRF 解决方案似乎坚持将 CSRF 令牌作为 POST 数据的一部分发送。
在我的情况下，发送的数据是 json，我不控制发送的内容（而且我不想开始弄乱 json）。因此，我正在考虑将 CSRF 令牌作为标头发送。但是，我的应用程序的遗留部分仍然需要能够在正文中发送令牌（例如从 html 表单提交）。
因此，如果正文或标头中出现有效的 CSRF 令牌，我的 CSRF 保护必须允许该请求。与坚持将令牌放在体内相比，这是否存在安全风险？
CSRF 是让一个不可疑的用户将数据发布到攻击者认为用户已登录的服务器。
保护背后的想法是，服务器将令牌与您的会话相关联，并将其作为 cookie 和有效负载要求发送给您。然后，当发布内容时，您将令牌以 cookie 的形式发送到有效负载中。因此，攻击者无法猜测 cookie 或会话中的令牌是什么。如果服务器收到带有两个不同令牌的帖子，它将被拒绝。
我认为将有效负载令牌放在标头中就可以了，只要它不是“Cookie”或浏览器“记住”并自动发送的任何其他标头即可。
如果您在 header 中发送 CSRF 令牌，不会有任何安全风险。只需确保每次客户端请求页面时此标头的值都会发生变化，即它应该是一个随机数。此外，客户端的 Web 应用程序应该将此标头发送回服务器，以便服务器可以将发送到客户端的标头值与从客户端响应接收到的相同标头的值进行匹配。
在请求头中发送CSRF更安全。
CORS 不会检查表单标签请求的同源策略，这意味着如果有人设法获取 CSRF 令牌，那么他可以使用来自不同域（来源）的表单标签发送 post 请求 但是如果在请求标头中发送CSRF，表单标签无法发送请求标头，他必须使用javascript（fetch（）或XmlHttpRequest（）），在这种情况下，CORS将阻止他，因为他是从不同的域发送的（起源）。
此防御依赖于同源策略 (SOP) 限制，即只能使用 JavaScript 添加自定义标头，并且只能在其源内。默认情况下，浏览器不允许 JavaScript 使用自定义标头发出跨源请求。
如果您的系统属于这种情况，您可以简单地验证所有服务器端 AJAX 端点上是否存在此标头和值，以防止 CSRF 攻击。这种方法具有双重优势，通常不需要更改 UI，也不需要引入任何服务器端状态，这对 REST 服务特别有吸引力。如果愿意，您可以随时添加自己的自定义标头和值。
这种技术显然适用于 AJAX 调用，但您仍然需要使用本文档中描述的方法（例如令牌）来保护表单标签。此外，CORS 配置也应该足够强大，才能使该解决方案有效运行（因为来自其他域的请求的自定义标头会触发飞行前 CORS 检查）。
只是从重要的技术角度对此进行阐述：
据我所知，在标头中返回 CSRF 令牌需要通过 AJAX 发送整个表单。这可能涉及对某些站点的客户端和后端进行重大返工，特别是如果由于请求而必须更新页面的许多部分，而该请求通常会导致使用更改的数据简单地重新生成整个页面。
因此它需要 JavaScript，否则可能不需要。
如果请求更改了所有者层次结构，则此类额外信息可能会更新面包屑路径，或者如果实体的状态发生更改，则可能会更新各种详细信息。
隐藏的表单字段可以是添加到每个表单的 HTMP 模板的一个简单部分，并且实现起来会简单得多。