Web Storage 无访问控制，防非法读取关键是使读取内容无意义：不存敏感数据、用 HttpOnly Cookie 管理登录态、前端加密（Web Crypto API）、限制脚本执行（CSP/SRI）、运行时监控异常读取。
核心原则是：Web Storage 本身没有访问控制机制，同源脚本可自由读写。所谓“防非法读取”，本质不是阻止读操作，而是让读到的内容无意义或无法被利用。
避免存储敏感数据是第一道防线
localStorage 和 sessionStorage 都属于客户端公开存储区，任何同源 JavaScript（包括第三方库、广告脚本、被注入的 XSS payload）都能调用 getItem() 遍历或提取内容。因此最有效的方式是根本不在里面存敏感信息：
- 不要存 JWT token、session ID、密码、银行卡号、身份证号等身份凭证或隐私字段
- 用户登录态优先用
HttpOnly + Secure + SameSite=Strict的 Cookie 管理 - 若必须缓存部分用户信息（如偏好设置、主题色），确保不包含可直接用于身份冒用的数据
对存入内容做前端加密处理
即使被读取，也无法解密还原原始数据。推荐使用浏览器原生 Web Crypto API 实现端到端加密：
- 生成一个仅在内存中临时存在的密钥（
crypto.subtle.generateKey()），不持久化、不暴露给全局作用域 - 写入前用 AES-GCM 加密明文，连同 IV 一起 base64 编码后存入 localStorage
- 读取时先解码，再用相同密钥和 IV 解密；密钥不参与存储，每次页面加载重新协商或派生（如通过用户密码派生）
- 注意：密钥管理仍是关键——绝不能硬编码、不能存在 localStorage 或全局变量中
限制脚本执行环境降低风险面
防止恶意脚本运行，比防范它读取 storage 更治本：
- 启用严格 Content-Security-Policy（CSP），禁用
'unsafe-inline'和'unsafe-eval'，强制所有脚本通过 nonce 或哈希加载 - 为所有外链资源添加 Subresource Integrity（SRI）校验，阻断 CDN 劫持导致的恶意脚本注入
- 移除未使用的第三方 SDK，尤其警惕自动注入 DOM 的分析/广告脚本
- 对富文本渲染使用
DOMPurify.sanitize()过滤，避免 HTML 注入触发后续 XSS
运行时监控异常读取行为
虽无法阻止合法脚本调用 getItem，但可识别非常规模式并预警：
- 重写
Storage.prototype.getItem方法，记录调用堆栈与频率 - 若 1 秒内出现 ≥10 次对同一 key 的读取，或调用来源非业务模块（如非
auth.js、user.js），触发告警或清空该 key - 配合 PerformanceObserver 监控长任务，识别可能正在执行 dump 脚本的主线程阻塞行为
- 注意：该方案不能替代前面三项，仅作为纵深防御的补充哨点
