为何CSRF防护要求客户端做额外适配？（Spring Boot场景）

你提到的这个点，本质是CSRF攻击防护逻辑的核心，不是多此一举，而是必须这么做才能真正起到防护作用，下面给你拆解清楚：

1. CSRF攻击的本质就是利用浏览器自动带Cookie的特性 #

CSRF攻击的套路是：攻击者诱导用户访问恶意页面，页面里悄悄发起目标服务器的修改类请求（比如转账、修改资料），浏览器会自动把用户在目标服务器的Cookie（包括会话Cookie）带过去。如果服务器只校验Cookie里的令牌，攻击者根本不需要知道令牌内容——浏览器会自动帮他带上，防护等于完全失效。

2. 双重提交Cookie模式（Spring Boot默认方案）的核心逻辑 #

Spring Boot的CSRF防护采用「双重提交Cookie」方案：

• 服务器生成CSRF令牌，把它放到HttpOnly=false的Cookie（XSRF-TOKEN）里，这样同源的前端应用可以用JS读取这个Cookie。
• 服务器要求前端在POST/PUT/DELETE等修改类请求里，把这个令牌放到请求头（X-XSRF-TOKEN）里。
• 服务器收到请求后，对比Cookie里的令牌和请求头里的令牌是否一致：
  • 合法的前端应用是同源的，能读取Cookie并设置请求头，所以能通过校验。
  • 攻击者的恶意页面是跨域的，受浏览器同源策略限制，无法读取用户的XSRF-TOKEN Cookie，自然没法把令牌放到请求头里，请求会被拦截。

3. 针对你疑问的具体解答 #

• 为什么浏览器不能自动带请求头？：Cookie是浏览器的自动行为，但请求头需要主动设置——这正是区分「用户主动发起的合法请求」和「攻击者伪造的请求」的关键。如果请求头也能自动带，攻击者的恶意请求照样能通过校验。
• 为什么Postman也要手动配置？：Postman不是浏览器环境，它不会自动帮你把Cookie里的令牌复制到请求头，所以需要你写脚本手动处理。而浏览器里的合法前端应用是同源的，可以轻松实现这个逻辑。
• 为什么服务器不直接读Cookie里的令牌？：如第一条所说，直接读Cookie的话，CSRF攻击就能绕过防护，等于白做了。

4. 补充：Spring Boot的配置细节 #

默认情况下，Spring Security的CsrfTokenRepository生成的XSRF-TOKEN Cookie是HttpOnly=false的，这是特意为了让前端JS能读取它。如果把这个Cookie设为HttpOnly=true，前端就没法读取了，防护逻辑就断了。

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