许多资源声称（source1）（source2）
对于RESTful Web服务公开的资源，确保任何PUT，POST和DELETE请求免受跨站点请求伪造的影响非常重要 . 所有应用程序都必须使用CSRF，而对Web安全性的关注度最低
但是the Spring Security docs说：
对普通用户可以由浏览器处理的任何请求使用CSRF保护 . 如果您只创建非浏览器客户端使用的服务，则可能需要禁用CSRF保护 .
那么，是否可以为应用程序禁用CSRF？
仅公开REST API
仅使用JSON（检查请求Content-Type标头）
这取决于您的API的客户端 . CSRF攻击基于以下事实：客户端使用HTTP请求自动发送所请求URL的cookie（授权） . 如果您的客户端没有这样做（通常浏览器自动执行此操作），您应该没问题 .
原因是：如果您的API使用者未通过cookie（由浏览器自动存储）在您的应用程序中进行身份验证/授权，则攻击者无法使用任何其他网页进行成功的CSRF攻击（使用Cookie从其他页面发送HTTP请求）您的API来自浏览器） .
换句话说，我无法想象您将以一种方式编写API客户端，它可以向您的API发送请求，存储cookie（您的身份验证），还可以以某种方式向您显示“愚蠢”用户交互的一些内容 - 发送通过以前的API请求中的Cookie（您的身份验证）向您的API请求 .
很容易解释这个：
基于 Http Session 生成CSRF令牌 . 如果您的API持有http会话，那么您需要使用CSRF令牌来保护它，但是大多数REST服务都设计为无状态，在这种情况下，您不能/不应该使用CSRF令牌 .
Http Session
2 回答
这取决于您的API的客户端 . CSRF攻击基于以下事实：客户端使用HTTP请求自动发送所请求URL的cookie（授权） . 如果您的客户端没有这样做（通常浏览器自动执行此操作），您应该没问题 .
原因是：如果您的API使用者未通过cookie（由浏览器自动存储）在您的应用程序中进行身份验证/授权，则攻击者无法使用任何其他网页进行成功的CSRF攻击（使用Cookie从其他页面发送HTTP请求）您的API来自浏览器） .
换句话说，我无法想象您将以一种方式编写API客户端，它可以向您的API发送请求，存储cookie（您的身份验证），还可以以某种方式向您显示“愚蠢”用户交互的一些内容 - 发送通过以前的API请求中的Cookie（您的身份验证）向您的API请求 .
很容易解释这个：
基于
Http Session生成CSRF令牌 . 如果您的API持有http会话，那么您需要使用CSRF令牌来保护它，但是大多数REST服务都设计为无状态，在这种情况下，您不能/不应该使用CSRF令牌 .