HTML5不提供加密机制，状态安全取决于传输方式与服务端验证；敏感数据禁放URL或history.state；前端加密仅防偶然查看，真正安全需后端签发JWT令牌并HTTPS传输。

HTML5 本身不提供页面间状态传递的“加密”机制，状态传递的安全性取决于你用什么方式传、传到哪、以及是否在服务端验证。所谓“加密”，其实是对敏感数据做保护处理，而非 HTML5 自带功能。关键不是“怎么加密”，而是“哪些状态不该明文传、怎么传更安全”。

别把敏感数据塞进 URL 或 history.state

很多人用 history.pushState() 或直接拼接 URL 参数（如 ?token=xxx）传用户 ID、权限、会话标识等——这等于把钥匙贴在快递单上。
URL 会被浏览器历史记录、服务器日志、代理缓存、Referer 头泄露，state 对象虽不暴露在地址栏，但仍在内存中可被 JS 读取，且刷新即丢失，无法替代服务端会话。

• ✅ 正确做法：只传轻量、非敏感的 UI 状态，比如 { tab: "settings", scrollTop: 1200 }
• ❌ 避免传：{ userId: "123", authKey: "abc...", role: "admin" }

用 sessionStorage / localStorage 做临时中转？先加密再存

如果必须前端暂存某些需跨页使用的数据（如表单草稿、筛选条件），且不能走后端 API，可结合 Web Crypto API 加密后再存：

• 生成一个仅当前会话有效的密钥（如用 crypto.subtle.generateKey()）
• 用 AES-GCM 加密数据，连同 IV 一起存入 sessionStorage
• 下个页面读取后解密（注意：密钥不可硬编码，也不该存在 localStorage）

⚠️ 注意：前端加密≠安全。只要代码可见，密钥或算法就可能被逆向。它防的是“偶然查看本地存储”，不是主动攻击者。

真正靠谱的方式：状态交给后端管，前端只持 Token

页面跳转时，不要传状态，而是传一个短期有效的、签名过的令牌（如 JWT），由后端验证并还原真实状态：

• 从 A 页面跳 B 时，请求后端接口生成一个带过期时间、绑定用户和上下文的 JWT
• 重定向到 B 页面时带上该 token（如 /b?st=eyJhbGciOi...）
• B 页面用 fetch 向后端校验 token，获取真实状态数据（服务端完成鉴权与解密）

这样既避免前端暴露逻辑，又防止篡改，还支持吊销和审计。

补充提醒：HTTPS 是一切的前提

无论用哪种方式，所有跨页状态传递都必须在 HTTPS 下进行。HTTP 明文传输 URL、Header、甚至 fetch 请求体，加密也白搭。浏览器也会对非 HTTPS 环境下的 crypto.subtle 等 API 施加限制。