Web Storage不支持跨域访问，因同源策略强制要求协议、域名、端口完全一致；可行方案包括postMessage协作、iframe代理或服务端统一托管；敏感数据禁存localStorage，应优先使用HttpOnly Cookie。
Web Storage（localStorage 和 sessionStorage）本身不支持跨域访问，这是浏览器同源策略的硬性限制，不是功能缺陷，而是安全基石。理解它怎么“卡住”、为什么不能绕过、以及在必须共享数据时如何安全地绕开，才是关键。
同源策略是铁律，不是可选项
协议、域名、端口三者完全一致才算同源。哪怕只是 http 和 https 的差别，或者 www.example.com 和 example.com 的细微不同，存储空间就彻底隔离。比如：
- 你在 https://shop.example.com 登录后存了 token 到 localStorage，用户跳转到 http://shop.example.com（少了 s），这个 token 就完全不可见；
- 主站 example.com 嵌入了子域 api.example.com 的 iframe，iframe 里的脚本无法直接读写父页的 localStorage；
- 两个不同域名的 SPA 应用，即使部署在同一台服务器上，也无法互相访问对方的 Web Storage。
别试图“突破”，而要“协作”
强行绕过同源策略既不可靠也不安全。真正可行的做法是让不同源页面通过受控通道交换信息，再各自存入自己的 storage：
-
postMessage + 本地存储：A 页面调用
window.postMessage()向 B 页面（已知其 origin）发送结构化数据，B 页面监听 message 事件，验证 origin 后再调用自身 localStorage.setItem()； - iframe 代理模式：在目标域下部署一个轻量级 HTML 文件（如 storage-proxy.html），作为“中转站”。主页面通过 postMessage 指令它操作自己的 localStorage，再把结果返回；
- 服务端统一托管：所有前端页面都通过 API 向后端请求/更新状态，storage 只作本地缓存或临时暂存，核心数据以服务端为准。
敏感数据绝不进 Web Storage
JWT、密码、身份证号等高敏感信息，一旦存入 localStorage，就等于暴露给当前域下的任意脚本——XSS 漏洞一出现，立刻失守。正确做法是：
- 认证 token 优先走 HttpOnly Cookie，配合 Secure 和 SameSite=Strict；
- 若必须前端持有（如某些 SPA 架构），至少做内存暂存（变量）、短期缓存（sessionStorage），并避免序列化到 localStorage；
- 确需加密存储时，用 Web Crypto API 加密后再存，但密钥管理本身又带来新复杂度，慎用。
权限最小化，验证不偷懒
如果采用 cross-storage 等第三方库实现跨域共享，务必严格配置 origin 白名单和允许方法：
- origin 匹配用精确正则，例如
/^https:\/\/(app|dashboard)\.mycompany\.com$/，拒绝/\.com$/这类宽泛写法； - 只开放必要操作，比如子应用只需读主题设置，就只 allow: ['get']，禁用 set/del；
- 每次接收 postMessage 时，必须校验 event.origin，绝不能只依赖 event.source 或忽略检查。
