不久前，我在工作中使用的一种软件中遇到了该选项，该选项通过在客户端包括一个特殊的HTTP标头值来关闭XSRF服务器端保护。因此，我想知道：
我现在怀疑我对XSRF保护的知识，由于我们无法在工作中达成共识，所以我决定在此发表我的担忧。
产品为Bamboo，他们在https://confluence.atlassian.com/bamkb/rest-api-calls-fail-due-to-missing-xsrf-token-899447048.html#RESTAPIcallsfailduetoMissingXSRFToken-Workaround中公开报告了该选项。我首先在这里的一个旧答案中提到了这一点：https://stackoverflow.com/a/45090321/410939。
我会回答这个问题：为什么要实施安全功能，然后要求用户将其打开？这是您可以在任何地方（例如实际上，没有人强迫2FA，即使它在安全性方面有很大的改进。
如果XSRF基于会话，并且您使用同一应用程序运行多个标签，而您被迫在其中一个中重新进行身份验证，则通常会获得一个新的XSRF令牌。然后，其他选项卡可能不再通过XSRF检查，从而丢失未保存的工作。可能还有其他类似的情况。
有时在安全性和可用性之间进行权衡，在这种情况下，它们使安全性成为默认设置，并让遇到问题的人承担知情的风险。
还有其他减轻XSRF的方法。因此，如果不是cookie的选择（也许客户端不支持cookie），则可能要禁用此cookie解决方案。
减轻XSRF的其他方法：
状态变量（Auth0使用它）-客户端将生成并随每个请求传递一个加密强度高的随机随机数，服务器将随其响应一起回显该随机随机数，从而允许客户端验证随机数。在Auth0 doc
始终检查引荐来源标头，并且仅在引荐来源为可信域时才接受请求。如果没有引荐来源标头或域名不在白名单中，则只需拒绝该请求即可。使用SSL / TLS时，通常会存在引荐来源网址。登陆页面（主要是信息性的，不包含登录表单或任何受保护的内容可能会稍微放松一些，并允许带有缺少引荐标头的请求