将Bearer Token拆分存储到Http-Only Cookie与LocalStorage是否更安全？

结论先行：这种拆分存储的方案并不合理，反而会增加系统复杂度与安全风险，建议根据业务场景选择单一存储方式，或采用更成熟的Token管理方案。

一、拆分存储的核心问题 #

• 徒增复杂度与故障点：每次API请求需要从两个存储位置取出Token片段拼接，前端逻辑冗余，一旦某一方存储失效（比如Cookie被用户清除、LocalStorage被恶意篡改），直接导致认证失败，排查问题的成本也会上升。
• 未真正规避原有风险：
  • LocalStorage的XSS风险依然存在：攻击者通过XSS漏洞窃取到LocalStorage中的Token片段后，结合Http-Only Cookie自动携带的另一部分，完全可以构造出合法的请求——因为Http-Only Cookie会在同域请求中自动发送，攻击者无需读取其内容，只需触发请求即可。
  • Http-Only Cookie的CSRF风险未解决：即便Token拆分，只要Cookie中的片段会被自动携带，攻击者仍可通过CSRF攻击发起请求，配合XSS获取的另一部分完成认证。
• 破坏Token的完整性设计：标准Bearer Token（如JWT）本身是一个完整的认证凭证，拆分后打破了其原有结构，服务器端的验证逻辑也需额外开发，容易引入新的逻辑漏洞。

二、更合理的存储选择 #

1. 优先选择Http-Only Cookie（适合传统Web应用） #

• 优势：从根源上避免XSS窃取Token（JS无法读取Http-Only Cookie）。
• 补充防护：配合CSRF Token机制（比如在请求头或表单中携带CSRF Token，服务器验证其与Cookie的关联性），即可有效抵御CSRF攻击。
• 关键配置：设置Cookie的Secure（仅HTTPS传输）、SameSite=Strict/Lax（限制跨域携带）、Max-Age（合理的有效期）属性，进一步提升安全性。

2. 使用LocalStorage（适合SPA单页应用） #

• 适用场景：纯SPA应用，后端支持CORS，需要前端主动将Token放入Authorization请求头。
• 必要防护：
  • 严格防范XSS：对所有用户输入做转义处理，配置Content-Security-Policy（CSP）限制脚本执行范围，避免恶意脚本注入。
  • 缩短Token有效期：使用短生命周期的Access Token，搭配存储在Http-Only Cookie中的Refresh Token，定期刷新Access Token，降低Token泄露后的风险。

3. 最优方案：Refresh Token机制 #

• 流程：将短有效期的Access Token存在LocalStorage（用于日常API请求），长有效期的Refresh Token存在Http-Only Cookie中。当Access Token过期时，前端通过携带Refresh Token的请求（Cookie自动发送）获取新的Access Token。
• 优势：既利用LocalStorage满足SPA的灵活请求需求，又通过Http-Only Cookie保护了Refresh Token，同时缩短Access Token有效期，降低泄露后的影响范围。

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