为何配置Spring Security CorsFilter后仍需启用CSRF防护？

你测试的场景中，非允许源的表单请求被CorsFilter拦截，但这只能说明CORS在这个特定场景下起作用，它和CSRF防护解决的是完全不同的安全问题，二者不能互相替代，具体原因如下：

1. CORS管「跨域请求合法性」，CSRF管「请求是否是用户自愿发起」 #

• CORS的核心是限制不同域名之间的请求交互，防止恶意网站随意调用你的后端接口，但它只在浏览器环境下生效，攻击者直接用工具（如curl、Postman）发送请求时，CORS规则完全无效。
• CSRF防护是验证请求是否来自用户信任的页面，不管请求是不是跨域，只要没有携带服务端生成的CSRF令牌，就拒绝请求，这是针对「冒充用户发起请求」这类攻击的根本防护。

2. 同源场景下CORS完全失效，CSRF是唯一防护 #

如果你的允许源（比如http://localhost:4200）存在XSS漏洞，攻击者可以在这个合法域名下注入恶意脚本。此时脚本发起的请求属于同源请求，CORS会直接放行，浏览器还会自动带上用户的认证Cookie（比如你配置的HttpBasic会话Cookie）。如果没有CSRF防护，攻击者可以冒充用户执行任意操作（比如修改用户信息、删除数据）。

3. 你的测试场景只是CORS生效的特例，还有很多场景CORS拦不住 #

你测试的是从非允许源提交表单被拦截，但：

• 如果攻击者诱导用户点击第三方网站的GET请求链接（比如http://localhost:8080/delete/user/1），这类请求属于浏览器正常跳转，CORS不会拦截，没有CSRF防护的话，后端会执行删除操作。
• 要是你的允许源被攻击者利用（比如子域名劫持），攻击者在允许源下发起的请求，CORS会直接放行，此时必须靠CSRF令牌验证请求合法性。

4. 你的CORS配置放大了风险 #

你设置了config.setAllowCredentials(true)，这意味着允许跨域请求携带用户的认证Cookie。如果此时关闭CSRF防护，只要攻击者能绕过CORS的Origin检查（比如通过某些浏览器漏洞、或者域名配置失误），就可以轻易冒充用户发起操作。

简单来说：CORS是一道「域门禁」，CSRF是一道「身份核验门」，门禁防的是外人随便进，但防不住已经进门的坏人；身份核验门才是确保每个请求都是用户本人意愿的关键。

内容的提问来源于stack exchange，提问作者asgarov1