SPA+JWT+不支持Cookie认证的REST API：安全存储方案问询

可行替代方案 #

除你提到的API改造和增设代理外，还有几种低成本或场景化的方案：

• 轻量反向代理做Token自动转换：如果无法管控目标API，可部署Nginx、Cloudflare Workers这类轻量代理。将JWT存入HttpOnly、Secure、SameSite=Strict的Cookie，代理拦截SPA的请求后，自动从Cookie中提取JWT，添加到Authorization: Bearer <token>请求头再转发给API。全程无需修改SPA和目标API，仅需配置代理规则，投入成本极低。
• 同域隐藏iframe中转Token：在SPA同域名下部署一个后端托管的隐藏iframe，登录流程由iframe完成，后端将JWT存入HttpOnly Cookie。SPA通过postMessage向iframe发起Token请求，iframe读取Cookie后回传给SPA。但这种方式存在XSS风险（若iframe被注入恶意代码），仅适合内部完全可控的场景。
• localStorage存储+极致XSS防护：如果不得不使用localStorage，必须强化XSS防护来降低风险：
  • 启用严格的Content-Security-Policy（如script-src 'self'），禁止内联脚本和未信任资源加载；
  • 对所有用户输入做严格过滤转义，避免DOM型XSS；
  • 缩短JWT过期时间，搭配刷新Token机制，减少Token泄露后的影响范围。

关于遵循Cookie存储最佳实践的实际情况 #

确实有大量团队在SPA+JWT+REST API架构下严格遵循Cookie存储的安全规范，主要集中在两类场景：

• API自主可控：团队直接改造REST API，使其支持从Cookie中提取JWT进行验证。同时将Cookie配置为HttpOnly、Secure、SameSite=Strict，并配合CSRF Token防护（SPA请求时在表单或请求头中携带CSRF Token），彻底规避localStorage的XSS泄露风险。
• 采用BFF架构：在SPA与后端API之间搭建BFF层，由BFF统一处理登录、Token存储和请求转发。SPA仅与BFF交互，BFF将JWT存入HttpOnly Cookie，调用下游API时自动添加Bearer Token头。这种架构在大型SPA项目中被广泛应用，既保障了安全，又能统一处理鉴权、请求聚合等前端适配逻辑。

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