history.pushState()的安全性如何？是否适合存储敏感密钥？

现有方案的核心风险 #

• XSS漏洞直接泄露：pushState存储的状态可以通过全局history.state属性直接读取，只要页面存在任意XSS漏洞，攻击者不需要额外权限就能直接获取所有存储的敏感密钥。
• 磁盘持久化泄露风险：主流浏览器为了支持崩溃恢复、会话重启功能，会将包括pushState状态在内的会话历史序列化后存储到本地磁盘文件中，即便页面关闭、浏览器退出，这些数据仍可能残留，存在被恶意软件、磁盘取证获取的可能。
• 物理接触泄露风险：如果用户临时离开设备没有关闭页面，其他人可以直接打开开发者工具，在控制台执行代码读取history.state中的内容，没有任何防护限制。
• 同源页面共享风险：同一域名下的所有页面共享同一份历史栈，如果你在当前页面存入的密钥没有手动清除，后续用户跳转到同域名下的其他页面，仍然可以通过回退历史读取到对应状态，若同域名下其他页面存在安全问题，也会导致密钥泄露。

方案合理性判断 #

该方案本身不是存储敏感信息的合理选择。history.pushState的设计初衷是用于单页应用的路由状态管理，没有为敏感数据存储做任何安全设计，所有防护仅依赖基础的同源策略，抗风险能力极弱。

更优的替代方案 #

根据你的使用场景可以选择不同方案：

• 仅需当前页面会话生效，刷新页面即可失效：将密钥存储在非全局的内存变量中，比如闭包、私有模块变量内，不要挂载到window等全局对象，尽可能缩小暴露面。
• 需要支持页面刷新、同标签页跨路由生效：选择sessionStorage存储，注意不要明文存储，需先对密钥做对称加密后再写入，加密密钥可使用用户登录后服务端下发的单次会话临时密钥，不要硬编码在前端代码中。sessionStorage会在标签页关闭后自动清除，风险远低于持久化存储。
• 需要长期存储、跨标签页生效：使用Web Crypto API对敏感密钥做AES等对称加密后，存储到IndexedDB中，加密密钥由用户自主输入的PIN码派生，不要固定在前端代码里。
• 高敏感级别的密钥（比如支付签名密钥、身份凭证）：优先使用浏览器原生的Credential Management API相关能力存储，这类存储由浏览器内核做安全隔离，普通JS无法直接读取，抗XSS能力远高于普通前端存储方案。

注：所有前端存储方案都无法完全免疫XSS攻击，做好页面的XSS防护（输入输出过滤、开启CSP策略）是所有敏感数据存储的前提。

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