H5 浏览器存储与数据安全

H5 常用浏览器存储保存主题、草稿、缓存和会话状态。它们使用方便，却不等同于安全保险箱。脚本运行在页面上下文中，一旦页面发生脚本注入，普通存储中的内容就可能被读取。设计存储方案时，应先考虑数据敏感度、生命周期和容量，再选择具体能力。

一、常见存储能力的差异

localStorage

以字符串形式长期保存，读写是同步的，适合少量用户偏好。大量读写会阻塞主线程，不适合高频或大体积数据。

sessionStorage

生命周期通常与当前标签页会话一致，适合短期页面状态。它仍然可以被同一页面上下文中的脚本读取，不能用于保存高敏感凭据。

IndexedDB

提供异步、结构化和更大容量的本地存储，适合离线数据和较大缓存。它需要处理版本升级、事务和清理策略。

Cookie

可以随符合条件的请求自动携带。身份相关 Cookie 应由服务端设置合适的安全属性，前端脚本不应假设自己能够或应该读取它。

二、先做数据分类

可以按风险和用途分类：

• 界面偏好：主题、列表密度等，可长期保存。
• 临时状态：当前筛选、未完成步骤，可短期保存。
• 离线业务数据：需要版本、容量和同步策略。
• 个人信息：只保存业务必需部分，并明确清理时机。
• 身份凭据和高敏感数据：遵循项目安全体系，不进入普通脚本可读存储。

选择存储前应回答为什么要保存、保存多久、谁能读取以及退出登录后如何处理。

三、为持久化数据增加版本

页面发布后，旧结构可能仍存在于用户设备中。可以给存储数据加入明确版本，并只实现真实存在的迁移路径。

type PreferencesV2 = {
  version: 2;
  theme: 'light' | 'dark' | 'system';
  compactMode: boolean;
};

function parsePreferences(raw: string): PreferencesV2 {
  const value: unknown = JSON.parse(raw);
  if (typeof value !== 'object' || value === null) {
    throw new Error('偏好数据格式错误');
  }

  const record = value as Record<string, unknown>;
  if (record.version !== 2) {
    return migratePreferences(record);
  }
  return validatePreferencesV2(record);
}

解析失败时如何处理取决于数据价值。可重新生成的偏好可以清除并使用默认值，用户离线草稿则不能随意丢弃。

四、封装命名空间和读写入口

键名散落在组件中容易冲突，也难以统一清理。

const StorageKeys = {
  preferences: 'app_preferences_v2',
  searchHistory: 'app_search_history_v1'
} as const;

class PreferenceStore {
  load(): PreferencesV2 | null {
    const raw = localStorage.getItem(StorageKeys.preferences);
    return raw ? parsePreferences(raw) : null;
  }

  save(value: PreferencesV2): void {
    localStorage.setItem(
      StorageKeys.preferences,
      JSON.stringify(value)
    );
  }

  clear(): void {
    localStorage.removeItem(StorageKeys.preferences);
  }
}

集中入口便于限制字段、记录版本和执行账户切换清理。不要调用清空全部存储的操作，以免误删同一环境下其他模块的数据。

五、控制同步存储的性能影响

localStorage 和 sessionStorage 的访问是同步的。不要在滚动、输入等高频事件里持续序列化大对象。

可以把频繁变化保存在内存中，在业务允许的时间点合并写入，例如字段失焦、页面进入后台或用户主动保存。关键数据不能只依赖页面卸载时写入，因为该时机不一定可靠。

六、使用 IndexedDB 事务

多个相关记录必须共同更新时，应放在同一读写事务中。事务完成前不要向上层报告保存成功。

数据库升级发生在版本变化时，升级函数只负责确定的结构变化，不应执行不可控的长网络任务。新增索引也要基于真实查询需求，过多索引会增加写入成本。

大批量数据应分批处理并监控容量。浏览器可能在存储压力下清理非持久数据，因此离线能力需要明确告知用户同步状态，不能把本地副本当作永不丢失的唯一数据源。

七、理解“前端加密”的边界

如果解密密钥也随页面代码提供，攻击者一旦能执行同上下文脚本，通常也能调用解密逻辑。因此，前端加密不能替代脚本注入防护和服务端安全设计。

加密仍可用于降低设备文件被直接读取时的风险，但密钥来源、轮换和恢复必须由完整方案支持。不要把固定密钥写在业务脚本中制造虚假的安全感。

八、降低脚本注入风险

用户输入展示到页面时，应使用文本方式渲染，避免直接拼接为 HTML。确实需要富文本时，使用项目统一的可信清理组件，并限制允许的标签和属性。

function renderNickname(element: HTMLElement, nickname: string): void {
  element.textContent = nickname;
}

依赖和第三方脚本同样运行在页面权限范围内，应控制来源、数量和升级流程。敏感信息最小化保存，能降低注入发生后的损失范围。

九、处理账户切换与退出

缓存键必须包含必要的账户隔离信息，或由每个账户独立命名空间管理。退出登录时，只清理当前账户专属数据和身份相关状态，不误删公共配置。

多标签页同时打开时，一个页面退出登录，其他页面也需要感知并停止敏感操作。项目可以使用已有的跨页面状态同步机制，但最终身份有效性仍以服务端判断为准。

十、建立检查清单

• 普通存储中是否出现身份凭据和高敏感数据。
• 持久化结构是否包含版本与真实迁移路径。
• 大对象是否在主线程高频序列化。
• 退出与切换账户是否精确清理数据。
• 用户输入是否通过文本方式输出。
• 离线数据是否有容量、过期和同步状态。
• 调试日志是否打印完整存储内容。

总结

浏览器存储首先是数据生命周期工具，不是安全边界。根据敏感度选择最小存储范围，为持久化结构建立版本和清理策略，减少脚本可读取的敏感内容，并用统一输出与依赖治理降低注入风险，才能让 H5 本地数据既可用又可控。