HTML5通过Web Crypto API支持AES-GCM加密，需严格保证IV唯一、密钥隔离及标签强制验证，才能实现机密性、完整性与真实性统一。

HTML5 本身不直接支持 GCM（Galois/Counter Mode）加密模式，它依赖浏览器提供的 Web Crypto API 来调用底层安全算法。GCM 是一种认证加密（AEAD）模式，能同时保证数据的机密性、完整性与真实性，比单纯使用 AES-CBC 更安全可靠。要在 HTML5 应用中正确启用 GCM 加密，关键在于规范使用 window.crypto.subtle 接口，并严格遵循密钥管理、IV（nonce）生成和标签验证等核心要求。

使用 SubtleCrypto 正确调用 AES-GCM

GCM 模式在 Web Crypto API 中通过 encrypt() 和 decrypt() 方法配合 "AES-GCM" 算法名使用。注意必须提供符合要求的参数对象：

• 算法对象需包含 name: "AES-GCM"、iv（12 字节推荐，也可 8–120 字节但须唯一）、additionalData（可选，用于认证关联数据）、tagLength（默认 128，常用 128 或 96）
• 密钥必须由 crypto.subtle.generateKey("AES-GCM", ...) 生成或通过 importKey() 安全导入，禁止硬编码或派生弱密钥
• IV 绝对不可复用：同一密钥下重复 IV 会导致 GCM 完全失效，建议用 crypto.getRandomValues(new Uint8Array(12)) 每次生成

解密时必须完整验证认证标签

GCM 加密输出 = 密文 + 认证标签（通常末尾 16 字节）。解密时 Web Crypto 会自动校验标签，但开发者需主动捕获错误：

• 若传入错误 IV、密钥或篡改过的密文/标签，decrypt() 会抛出 DataError 或 OperationError，不能忽略异常
• 不要自行拼接或截断返回结果；解密成功即代表数据未被篡改，无需额外哈希校验
• 若业务需携带元数据（如用户 ID、时间戳），应放入 additionalData 参数，它参与认证但不加密

规避常见安全隐患

很多“看似加密”的实现实际丧失 GCM 的安全优势：

立即学习“前端免费学习笔记（深入）”；

• 避免手动实现 IV 传递逻辑：IV 可明文传输（如 Base64 编码后与密文拼接），但必须确保接收方原样传回 decrypt()，不可做任何转换或填充
• 不混用密钥：一个密钥只能用于单一目的（如仅加密用户凭证），不可同时用于签名、派生其他密钥或不同算法
• 不降级到无认证模式：禁用 AES-CBC、AES-ECB 等无完整性保护的模式，即使它们在旧浏览器中兼容性更好

兼容性与兜底建议

目前所有主流现代浏览器（Chrome 43+、Firefox 34+、Edge 17+、Safari 11.1+）均完整支持 AES-GCM。若需支持 Safari 10.x 或更旧版本：

• 优先升级目标环境，而非妥协加密方案
• 确需兼容时，可用 isSupported 检测：if ("AES-GCM" in window.crypto.subtle?.getAlgorithms?.())
• 不推荐 fallback 到非 AEAD 方案；如必须，至少组合 HMAC-SHA256 + AES-CBC 并严格执行 Encrypt-then-MAC

真正发挥 GCM 价值，不在于是否调用了 API，而在于是否守住 IV 唯一性、密钥隔离性和标签强制验证这三条底线。只要这三点做到位，HTML5 应用就能在客户端获得接近服务端级别的加密保障。