web storage 不具备加密和访问控制能力，安全性依赖同源策略和xss防护；敏感数据严禁存储其中，应使用httponly cookie或内存变量；防御核心是输出编码、csp及框架安全实践。
Web Storage（包括 localStorage 和 sessionStorage）本身不提供加密或访问控制，其安全性完全依赖于同源策略和前端运行环境。一旦页面被 XSS 攻击成功，攻击者可直接读取、篡改甚至删除其中存储的数据——尤其是当敏感信息（如 Token、用户标识、临时凭证）被错误地存入时，风险极高。因此，Storage 的“安全机制”不是靠它自己实现的，而是靠开发者主动规避误用，并配合 XSS 防御体系共同构建。
Web Storage 本身不具备防护能力
localStorage 和 sessionStorage 是纯客户端存储，无服务端校验、无自动加密、无权限分级。它们遵循浏览器同源策略（Same-Origin Policy），即只有同协议、同域名、同端口的脚本才能访问。但该策略对 XSS 完全失效：只要恶意脚本在同一源下执行（例如通过存储型 XSS 注入到后台管理页），就能调用 window.localStorage.getItem('token') 瞬间获取全部内容。
常见误区：
- 以为设了
HttpOnlyCookie 就能替代 localStorage 存 Token —— 实际上，HttpOnly对 Storage 无效，且前端仍需读写 Token 时，Storage 仍是高危载体； - 认为“只存前端用的数据就没事”——但攻击者可利用存储数据构造二次攻击，比如篡改缓存的用户角色字段绕过前端权限判断；
- 未清理过期或废弃的 key，导致历史敏感数据长期滞留，扩大泄露面。
敏感数据绝不能存入 Web Storage
这是最直接、最有效的安全底线。Token、密码片段、身份证号、手机号、会话密钥等任何可用于身份冒用或业务越权的信息，一律禁止写入 localStorage 或 sessionStorage。
推荐做法：
- 认证凭证优先使用
HttpOnly + Secure + SameSite=Strict的 Cookie，由后端签发并自动携带，前端 JS 无法读取； - 如必须在前端持 Token（如 SPA 调用 API），应短期存于内存变量（如 React 的 state、Vue 的 reactive 对象），页面刷新即丢失，避免持久化；
- 确需缓存非敏感数据（如用户主题偏好、表单草稿、分页参数），应明确命名空间（如
app:ui:theme），并定期清理过期项。
输出编码 + CSP 是阻断 XSS 利用的关键
即使 Storage 中没有敏感数据，XSS 仍可能通过它发起其他攻击，比如将恶意 payload 存入 Storage，再由某个未做转义的模板渲染出来（DOM-based XSS）。因此，防御重点不在 Storage 本身，而在防止脚本执行。
核心措施：
- 所有用户输入内容在插入 HTML 前必须进行上下文敏感的编码：HTML 内容用
textContent或innerText渲染；动态插入 HTML 时使用 DOMPurify 过滤； - 服务端返回的响应头中强制启用
Content-Security-Policy，至少包含script-src 'self'，禁用内联脚本与eval，大幅压缩 XSS 执行条件； - 对从 Storage 读取并用于 DOM 插入的数据，视同用户输入处理——绝不直接
innerHTML = localStorage.getItem(...)，而应先转义或白名单过滤。
结合现代框架的默认防护机制
React、Vue、Svelte 等主流框架默认对插值内容（如 {userInput}）做 HTML 转义，天然防御大部分反射型和存储型 XSS。但需注意边界场景：
- React 的
dangerouslySetInnerHTML、Vue 的v-html、Svelte 的{@html ...}会绕过默认防护，使用前必须确保内容已由 DOMPurify 处理； - 框架组件若从 Storage 读取数据并直接用于动态属性（如
:src="storedUrl"），仍可能触发基于属性的 XSS（如javascript:alert(1)），需额外校验协议白名单； - 服务端渲染（SSR）应用中，Storage 在首屏不可用，但 hydration 后若未同步清理或校验，可能引发状态不一致与潜在注入点。
