Next.js应用中如何安全存储JWT 解决路由切换状态丢失问题

首先纠正一个常见认知偏差：Next.js 常规路由跳转是软导航，不会触发整页刷新，Redux、React Context这类内存里的全局状态在路由切换时会完整保留；只有首次加载站点、手动触发浏览器硬刷新、跨根布局的强制导航才会清空客户端内存状态，这也是纯内存存JWT会失效的核心场景。

下面按安全优先级从高到低给出可落地的方案，完全规避localStorage/sessionStorage的XSS泄露风险：

方案1：HttpOnly 安全Cookie存储（生产环境首选，安全等级最高） #

这是行业内通用的最稳妥方案，从根源上避免JWT被客户端JS窃取：

• 存储逻辑：用户登录校验通过后，服务端直接通过Set-Cookie响应头把JWT写入Cookie，不要把JWT返回到响应体里暴露给前端JS。写入Cookie时必须配置以下安全属性：
  • 加HttpOnly标记：完全禁止前端JavaScript读取该Cookie，XSS攻击无法窃取令牌
  • 加Secure标记：仅HTTPS协议下才会传输该Cookie，避免HTTP明文传输泄露
  • 配置SameSite=Strict或Lax：阻止跨站请求自动携带Cookie，防CSRF攻击
  • 匹配JWT有效期设置Max-Age，敏感业务场景可以缩短有效期配合刷新逻辑
• 读取逻辑：
  • 服务端组件、Server Action、Route Handler里直接调用Next.js内置的cookies()API就能读取JWT做校验，不需要经过客户端
  • 客户端组件请求同域接口时，浏览器会自动携带符合规则的HttpOnly Cookie，前端根本不需要手动读JWT、拼请求头
  • 如果需要调用跨域第三方接口，不要在客户端直连，在Next.js服务端写一层转发代理，由服务端读取JWT后请求第三方接口，再把结果返回给前端，全程不暴露令牌

方案2：短有效期JWT内存存储 + 静默刷新兜底（仅适用于必须在客户端拿到JWT的特殊场景） #

如果你的业务要求必须在客户端拿到JWT做本地签名、端侧加解密这类操作，不要用持久化存储，用双层逻辑解决硬刷新丢状态的问题：

• 初始化逻辑：
  1. 应用启动、硬刷新后全局状态为空时，自动调用一个静默校验接口（比如/api/auth/get-access-token），这个接口通过存在HttpOnly Cookie里的长期刷新令牌校验用户身份，校验通过后在响应体返回一个有效期15分钟以内的短期访问JWT
  2. 拿到短期JWT后直接存入Redux/Context这类全局内存状态，后续软导航路由切换时直接从全局状态读，不会有重复请求
• 兜底逻辑：
  1. 全局封装请求拦截器，当接口返回401、或者全局状态里拿不到JWT时，自动调用静默接口拿新的短期JWT，更新到全局状态后重试失败请求
  2. 加一个定时轮询，在JWT过期前2分钟自动触发刷新，避免用户操作中途令牌失效
• 安全注意：长期有效的refresh token绝对不能返回给客户端，必须存在HttpOnly Cookie里，就算短期access token因为XSS泄露，攻击者也拿不到长期登录凭证，风险远低于localStorage存储的长期JWT

避坑说明 #

• 不要用非HttpOnly的普通Cookie存JWT，这种Cookie能被前端JS读取，XSS场景下和localStorage一样容易泄露
• 不要把JWT硬编码注入到window全局变量里，这种方式同样能被任意前端脚本读取，没有安全增益
• 方案2里的短期JWT有效期绝对不要设太长，最长不要超过1小时，把泄露后的风险窗口压到最小

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