使用Http-only Cookie存储JWT搭配CSRF Token的作用是什么？

首先得明确两个攻击的本质区别：

• CSRF攻击：攻击者没法读取用户浏览器里的目标网站Cookie（同源策略限制），只能靠诱导用户点击链接/加载恶意页面，让浏览器自动携带Cookie向目标服务器发请求。但攻击者完全控制不了请求里的自定义内容（比如特定Header、请求体参数）。
• XSS攻击：攻击者能把恶意脚本注入到你的网站页面里，直接读取页面DOM、非Http-only Cookie等所有前端可访问的数据——这种情况属于网站本身的高危漏洞，需要单独通过输入过滤、CSP等手段修复，CSRF Token本来就不是用来防XSS的。

回到CSRF Token的核心作用，它的防御逻辑是这样的：

1. 用户登录后，服务器生成一个唯一的CSRF Token，同时做两件事：
   • 把Token存入一个非Http-only的Cookie（但同源策略下，其他网站根本读不到这个Cookie）；
   • 把Token渲染到当前页面的DOM里（比如隐藏的表单字段、<meta>标签，或者前端框架的全局状态中）。
2. 当用户发起敏感操作（比如改密码、提交订单）时，前端必须从DOM或非Http-only Cookie中取出Token，以**自定义Header（比如X-CSRF-Token）**或者请求体参数的形式，和Http-only的JWT Cookie一起发给服务器。
3. 服务器收到请求后，会同时验证：
   • Http-only Cookie里的JWT是否合法（确认用户身份）；
   • 请求里的CSRF Token和Cookie里的Token是否一致（确认这个请求是用户在你的合法页面上主动触发的，不是恶意网站诱导的）。

针对你提到的疑问逐一拆解：

• 为什么CSRF Token不能设为Http-only？因为前端需要主动读取并携带它，如果设为Http-only，前端JS拿不到，就没法在请求里带上，这层验证就完全失效了。
• 那存在被XSS窃取的风险怎么办？如果你的网站有XSS漏洞，那别说CSRF Token，攻击者直接就能通过脚本模拟用户发起任何请求（同源请求不受限制），这时候任何基于前端的防御都没用。CSRF Token的防御目标是在没有XSS漏洞的前提下，挡住跨域的CSRF攻击，XSS是另一个需要单独解决的问题。
• 为什么这就能防CSRF？因为恶意网站跨域访问你的网站时，读不到你的页面DOM，也读不到你的Cookie（不管是不是Http-only），所以拿不到CSRF Token。它只能诱导浏览器发请求，但请求里没有正确的Token，服务器直接就拒绝了。

总结一下：Http-only JWT是为了避免被XSS窃取用户身份凭证，而CSRF Token是为了在同源策略的基础上，确保请求是用户主动发起的合法操作——两者配合，分别覆盖了不同的攻击场景，缺一不可。

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