不建议用sessionStorage存储真正敏感的数据，它仅适合临时缓存非认证类会话数据（如UI状态、表单草稿），因数据明文可读、易受XSS攻击，且关闭标签页才自动清除，必须配合后端校验与主动清理。
不建议用 sessionStorage 存储真正敏感的数据（如密码、身份证号、支付令牌等），因为它本质上是前端可读、可篡改的存储机制，且不提供加密或访问控制。但它适合存那些“敏感但仅需临时存在、不涉及安全边界”的会话级数据——比如用户登录后的临时偏好、未提交的表单草稿、轻量级身份上下文（如用户ID+角色，前提是后端已校验且不用于鉴权）。
明确 sessionStorage 的安全边界
sessionStorage 仅在当前浏览器标签页生命周期内有效，关闭标签即清空，同一域名下不同标签页互不共享。它比 localStorage 更具隔离性，但仍完全暴露在 JavaScript 环境中：任何运行在该页面上的脚本（包括第三方库、恶意 XSS 脚本）都能读写它。
- ✅ 适合：临时缓存、UI 状态、非认证类上下文（如“当前选中的语言”、“最近搜索关键词”）
- ❌ 不适合：token（应使用 httpOnly Cookie）、密码、银行卡号、JWT payload（除非仅作展示且后端不信任其内容）
- ⚠️ 注意：不要将它当作“安全存储”，而应视为“会话级临时缓存”
存入前做最小化处理
即使数据本身不直接涉密，也应避免存原始敏感字段。优先存 ID 或摘要，而非明文；必要时做轻量脱敏或映射。
- 例如：存
{ userId: "u123", role: "editor" }可以，但不要存{ name: "张三", idCard: "110..." } - 对字符串值可简单哈希（如用
crypto.subtle.digest计算 SHA-256）后再存，用于校验一致性而非保密 - 避免 JSON.stringify 后直接存大对象——可能意外包含敏感字段，建议显式 pick 需要的键
配合后端做双重校验
前端存什么，后端必须重新验证。sessionStorage 中的数据绝不应绕过服务端鉴权或参数校验。
- 例如：前端存了
activeTab: "payment"，跳转时只用来渲染 UI，实际接口请求仍需携带 session cookie 并由后端判断用户是否有权限访问该 tab 对应资源 - 若需传递上下文（如“从哪个页面跳转而来”），可用短时效、一次性的签名参数替代明文存敏感路径
- 关键操作（如提交、支付）前，强制后端重新拉取权威状态，不信任前端传来的任何 sessionStorage 衍生值
主动清理与失效管理
不要依赖浏览器自动清除。在业务逻辑明确结束时（如登出、切换账号、完成流程），主动调用 sessionStorage.removeItem() 或 clear()。
- 监听
beforeunload或pagehide事件做清理（注意兼容性和触发时机限制） - 对多步骤流程，每步完成后及时清理上一步的中间数据，减少残留风险
- 可在封装的 storage 工具中加入时间戳和过期检查，比如存入时附带
expires: Date.now() + 5 * 60 * 1000，读取时先校验是否过期
本质上，sessionStorage 是一个便利工具，不是安全容器。它的价值在于简化前端状态管理，而不是保护数据。把安全责任交给后端，前端只负责“临时、可见、可丢弃”的协作信息。
