React应用JWT存储安全：Cookie对比Local Storage的优势及最优方案

你提到的疑惑非常关键——默认情况下Cookie确实能被JS访问，但Cookie支持一系列强制安全属性，而Local/Session Storage完全没有这些防护能力，这才是核心差异：

• HttpOnly 属性：这是最关键的一点。标记为HttpOnly的Cookie无法通过JavaScript的document.cookie读取或修改，直接切断了XSS攻击窃取JWT的路径——毕竟XSS攻击的核心就是通过注入恶意脚本，获取页面中可被JS访问的敏感数据（Local/Session Storage完全暴露在JS面前，一遭XSS就会被窃取）。
• Secure 属性：强制Cookie只能在HTTPS连接下传输到服务器，避免了明文HTTP传输时被中间人截获的风险。Local/Session Storage的内容在JS调用时，不管HTTP/HTTPS都能被发送到任意地址，毫无限制。
• SameSite 属性：可以限制Cookie的跨站发送行为，有效防御CSRF攻击。比如设置SameSite=Strict时，Cookie只会在同站请求中发送；SameSite=Lax则允许部分安全的跨站请求（比如用户点击链接跳转）。而Local/Session Storage的内容可以被任意跨站脚本（如果存在XSS）窃取并发送，没有这类限制。

相比之下，Local/Session Storage本质上就是浏览器给JS提供的存储容器，没有任何内置的安全防护机制，一旦页面被XSS注入，存储在里面的JWT几乎是必然会被盗取的。

基于安全层面的最优实践，我推荐以下方案：

1. 用配置齐全的HttpOnly Cookie存储JWT

   • 必须添加HttpOnly、Secure、SameSite=Strict（或Lax，根据业务跨站需求调整）属性；
   • 设置合理的过期时间（比如15-30分钟），缩短JWT被盗用后的危害窗口；
   • 避免设置Domain属性（除非必要），缩小Cookie的作用范围，减少跨子域风险。

2. 优化JWT本身的安全设计

   • 绝不往JWT的Payload里存储敏感信息！Payload是Base64编码的明文，任何人都能解码查看，仅存放非敏感的用户标识（比如用户ID、角色）即可；
   • 使用非对称加密算法（如RS256）签名JWT：服务器用私钥签名，客户端/API用公钥验证，即使公钥泄露，攻击者也无法伪造JWT；
   • 避免过长的JWT，减少传输负担的同时，降低被截获的概率。

3. 强化XSS防御（即使用了HttpOnly Cookie也不能放松）

   • 对所有用户输入做严格的验证和转义，避免恶意脚本注入；
   • 启用内容安全策略（CSP），限制页面可加载的脚本、样式等资源来源，从根源上阻止未知脚本执行；
   • 避免使用eval()、innerHTML等高风险API，减少XSS攻击面。

4. 搭配Refresh Token机制

   • 用另一个HttpOnly Cookie存储长期有效的Refresh Token（同样配置Secure、SameSite属性），用来在Access Token过期时获取新的Access Token；
   • 服务器端要维护Refresh Token的状态（比如存储在数据库中），支持用户主动登出时失效，或者在用户更换设备时自动失效；
   • 采用滚动刷新机制：每次获取新Access Token时，同时返回一个新的Refresh Token，进一步降低Refresh Token被盗用的风险。

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