SessionStorage 不安全，不能存储敏感凭证；只能存短期 access_token、会话 ID、校验标记、过期时间戳等低风险数据，并需配合 HTTPS、服务端校验与 HttpOnly Cookie 等机制。
SessionStorage 本身不加密、不防 XSS，不能直接“安全存储”敏感凭证——它的定位是临时、会话级、前端可读的缓存容器。真正安全的做法，是**不存敏感原始凭证，只存必要且低风险的会话标识，并配合服务端强校验与传输层防护**。
只存非敏感、短期有效的会话标识
敏感凭证（如完整 JWT、私钥、refresh_token、密码）绝不能写入 sessionStorage。可存的仅限以下几类：
- 短期 access_token 字符串：由服务端签发、有效期短（如 15–30 分钟）、无签名密钥泄露风险的 token；
- 会话唯一 ID（如 sessionId）：纯服务端生成的随机字符串，本身无业务含义，仅作后端查表索引用；
- 签名片段或校验标记（如 session_signature）：用于前端请求前做轻量一致性校验，不包含密钥信息；
- 过期时间戳（如 tokenExpireAt）：数值型，便于本地快速判断是否已失效，避免无效请求。
写入时避免常见风险操作
写入不是简单 setItem，需控制内容来源与结构：
- 从登录响应中直接提取字段赋值，不拼接、不 base64 编码、不 JSON.stringify 简单字符串；
- 若需存对象（如 {token: "...", expireAt: 1735689200000}），用 JSON.stringify 序列化，但读取时必须 try-catch 防解析失败；
- 不存任何用户身份明文（手机号、身份证号）、密钥、refresh_token——后者应走 HttpOnly Cookie；
- 键名保持语义清晰（如 'session_token' 而非 'a1'），但不暴露逻辑（避免 'admin_token' 这类可推测字段）。
读取与使用全程校验有效性
不能假设 sessionStorage 中的数据“可信”，每次使用前必须验证：
立即学习“前端免费学习笔记（深入）”；
- 检查值是否存在且非 null/undefined；
- 解析后验证结构（如 token 是否含 '.' 分隔的 JWT 段、expireAt 是否为有效数字）；
- 对比当前时间与 expireAt，过期则立即 removeItem 并跳转登录；
- 发起请求前，将 token 放入 Authorization header（如 Bearer xxx），不放 query 或 body 中；
- 关键操作（如支付、删数据）必须由服务端二次鉴权，不依赖前端任何存储结果。
配合基础安全机制落地
sessionStorage 的安全性无法脱离整体链路：
- 强制 HTTPS：防止中间人窃取 token 或篡改响应；
- 服务端签发 token 时启用 exp 和 jti（唯一标识），支持主动吊销；
- 前端代码不打印 token 到 console，生产环境移除所有敏感日志；
- 登出时调用
sessionStorage.clear()或逐项 removeItem，不遗留残留； - 接受 XSS 风险现实——若页面存在高危漏洞，sessionStorage 内容必然可读，因此核心凭证仍应由服务端控制生命周期。
