SessionStorage 不安全，不建议用于身份认证；其数据仅限当前标签页、无加密和访问控制、易受XSS窃取，且不支持HttpOnly等安全属性。
SessionStorage 保存 Token 不安全，不建议用于身份认证场景。
SessionStorage 的本质限制
SessionStorage 是浏览器提供的内存级存储，数据仅在当前标签页生命周期内有效，关闭标签页即清除。它不提供任何加密或访问控制机制，所有 JavaScript 脚本（包括第三方库、恶意脚本、XSS 注入代码）均可读写其中的内容。
- 一旦页面存在 XSS 漏洞，攻击者可直接执行
sessionStorage.getItem('token')窃取 Token - 无法防止中间人篡改（虽本身不传输，但若 Token 后续通过 JS 发送到后端，仍依赖请求层面防护）
- 不支持 HttpOnly、Secure、SameSite 等 Cookie 安全属性，无法规避基础 Web 攻击面
比 SessionStorage 更合适的选择
Token 存储方式应匹配其用途与风险等级。临时会话类 Token 推荐以下组合：
- HttpOnly + Secure + SameSite=Strict 的 Cookie：服务端签发，JS 无法读取，天然防 XSS；配合 HTTPS 和严格同源策略降低泄露风险
- 内存变量（如模块级 const 变量）+ 短期有效期：Token 仅保留在运行时内存中，页面刷新即失效，适合高敏感操作（如银行转账确认页）
- IndexedDB 加密存储（需谨慎）：仅当必须本地持久且有强加密能力时考虑，但需自行实现密钥管理与加解密逻辑，复杂度高、易出错
如果必须用 SessionStorage，请加固使用方式
现实中部分项目受限于架构或历史原因仍采用该方式，此时应叠加多层缓解措施：
立即学习“前端免费学习笔记（深入）”；
- Token 本身设为短期有效（如 15 分钟），服务端强制校验时间戳与一次性使用（避免重放）
- 绑定设备指纹或请求上下文（如 User-Agent Hash、IP 段、TLS 会话 ID），服务端做一致性校验
- 关键操作前重新验证用户身份（如二次密码、短信验证码），不依赖单一 Token
- 前端启用严格 CSP 策略，禁用内联脚本与未授权外部资源，大幅压缩 XSS 利用空间
Token 安全是端到端问题，存储只是其中一环。SessionStorage 不是设计用来保护敏感凭证的容器，依赖它等于把钥匙挂在门把手上——方便自己，也方便别人。
