React项目中JWT存SessionStorage走Authorization头还是存带安全属性的Cookie更安全？

• 第一，React的自动转义从来不是XSS的免死金牌。实际开发中能触发XSS的场景根本绕不开：为了实现富文本展示用dangerouslySetInnerHTML、引入的第三方组件存在未过滤的XSS逻辑、前端路由把未校验的URL参数直接拼接进DOM、甚至富文本编辑器本身的XSS漏洞——这些场景下React的默认转义完全帮不上忙。而只要存在任意一个可利用的XSS点，跑在同源上下文的恶意脚本可以无阻碍地读取SessionStorage里的所有内容，把JWT直接打包外发，没有任何拦截手段。
• 第二，Authorization头规避CSRF的逻辑是有前提的。CSRF的核心原理是浏览器会自动在跨站请求中带上目标域的Cookie，如果你完全把API的鉴权链路切到Authorization头、从后端彻底关闭对Cookie携带凭证的接受能力，那确实从原理上消除了Cookie自动携带带来的CSRF攻击面。但如果后端同时兼容两种鉴权方式，攻击者根本不需要碰你前端存在SessionStorage里的JWT，只要诱导用户发带Cookie的跨站请求就能完成攻击。

• SessionStorage + 前端通过Authorization头携带JWT
  • 优势：不存在浏览器自动附带凭证的行为，只要后端严格不接收Cookie鉴权，CSRF的攻击面几乎可以忽略；JWT只存在于当前标签页的会话内存中，关闭标签页就自动清除，不会长期泄露。
  • 硬伤：对XSS的防御完全没有纵深——只要XSS触发，JWT就等于直接暴露，没有任何兜底机制。
• 设置Secure + HttpOnly + SameSite属性的Cookie存储JWT
  • 优势：HttpOnly属性会直接禁止同源JS读取Cookie内容，哪怕站点被注入XSS脚本，攻击者也偷不到存在Cookie里的JWT，这是XSS防护体系里最可靠的最后一道防线；Secure属性保证Cookie只会在HTTPS下传输，不会在明文链路中泄露。
  • 硬伤：因为浏览器会自动在请求中携带Cookie，一旦SameSite属性配置错误、或者兼容老版本浏览器，就存在CSRF的利用空间。但目前现代浏览器对SameSite属性的默认支持已经覆盖绝大多数用户，只要配置成SameSite=Lax或Strict，CSRF的实际利用门槛已经非常高。

不存在绝对的安全，核心是看你站点的风险敞口：

• 如果你做的是完全没有动态HTML渲染的纯内部工具，所有页面内容都是静态的、完全不接富文本、所有DOM渲染都严格走React的转义逻辑、连dangerouslySetInnerHTML都从来不用，那SessionStorage+Authorization头的方案在实际运行中确实风险很低，因为你根本没有可被XSS利用的入口。
• 只要你的站点存在用户生成内容、富文本展示、第三方自定义渲染这类动态HTML场景，那带HttpOnly属性的Cookie方案是更稳妥的选择。毕竟实际项目里，你永远没法拍胸脯保证自己写的每一行代码、用的每一个第三方依赖都没有XSS漏洞，而HttpOnly是唯一一个不管前端XSS怎么漏，都能保住用户登录凭证的兜底机制。
• 很多人觉得“SessionStorage因为能防CSRF所以更安全”，本质上是把风险概率算反了：从公开的漏洞统计来看，XSS的实际出现频率远高于配置不当导致的CSRF漏洞，为了规避一个已经被SameSite大幅降低风险的问题，放弃对XSS的纵深防御，是得不偿失的选择。

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