HTML5 依赖 Web Crypto API 实现前端加密，支持 AES-GCM 对称加密、PBKDF2 密钥派生及 SHA-256 哈希；须在 HTTPS 下运行，注意防范 XSS、避免前端处理高敏明文，并优先将核心加解密移至服务端。
HTML5 本身不提供直接的“数据加密 API”，但结合现代浏览器支持的 Web Crypto API，前端可在 JavaScript 层安全地实现加密、解密、签名与哈希等操作。关键前提是：加密必须在可信上下文（如 HTTPS 页面）中进行，且需明确加密目的——是保护本地存储数据？还是为传输前预处理？抑或实现端到端加密？不同场景策略不同。
使用 Web Crypto API 进行对称加密（如 AES-GCM）
这是最常用、性能好、支持度高的方式，适合加密敏感字段（如 token、用户偏好、离线缓存内容）。AES-GCM 同时提供加密与认证，防止篡改。
- 需先调用
crypto.subtle.generateKey("AES-GCM", true, ["encrypt", "decrypt"])生成密钥（或从口令派生） - 使用
crypto.subtle.encrypt({ name: "AES-GCM", iv, tagLength: 128 }, key, data)加密 ArrayBuffer 数据 - IV（初始向量）必须唯一且随机（每次加密用新
crypto.getRandomValues(new Uint8Array(12))），不可复用 - 密文、IV、算法参数需一并保存或传输，解密时缺一不可
基于口令的密钥派生（PBKDF2 或 HKDF）
当用户输入密码作为加密依据时，不能直接用口令当密钥。应通过 PBKDF2（推荐）或 HKDF 派生强密钥：
- 调用
crypto.subtle.importKey("raw", encoder.encode(password), {name: "PBKDF2"}, false, ["deriveKey"]) - 再用
crypto.subtle.deriveKey({name: "PBKDF2", salt, iterations: 100_000, hash: "SHA-256"}, baseKey, {name: "AES-GCM", length: 256}, true, ["encrypt", "decrypt"]) - salt 必须随机且唯一（每用户/每次加密独立生成），并和密文一同持久化
避免常见误区与安全边界
前端加密 ≠ 数据绝对安全。务必清醒认识其局限性：
Snowy(SnowyAdmin)快速开发平台3.5.1
下载
Snowy（SnowyAdmin）是国内首个国密前后端分离快速开发平台，集成国密加解密插件， 软件层面完全符合等保测评要求，同时实现国产化机型、中间件、数据库适配，是您的不二之选！ 技术框架与密码结合，让更多的人认识密码，使用密码；更是让前后分离“密”不可分。采用SpringBoot+MybatisPlus+AntDesignVue+Vite 等更多组件及前沿技术开发，注释丰富，代码简洁，开箱即用
立即学习“前端免费学习笔记（深入）”；
- 无法防御 XSS：恶意脚本可直接读取内存中的明文或密钥，因此不应在前端加密高敏感原始数据（如银行卡号、身份证号）
- 本地存储仍可被清除或导出：localStorage/sessionStorage 中的密文若被窃取，配合 salt 和迭代次数可能被离线暴力破解（尤其弱口令）
- 密钥管理是难点：浏览器不提供安全密钥存储（类似 TPM），密钥通常需内存驻留或由用户口令动态派生
- 不要自行实现加密逻辑、不要用过时算法（如 MD5、SHA1、DES）、不要忽略完整性校验
轻量替代方案：仅哈希 + 盐值（适用于密码摘要等场景）
若只需单向验证（如客户端校验表单密码强度、生成确定性标识符），可用 crypto.subtle.digest()：
-
crypto.subtle.digest("SHA-256", encoder.encode(input + salt))返回 ArrayBuffer 哈希值 - 注意：哈希 ≠ 加密，不可逆，仅适用于无需还原原始数据的场景
- 禁止用哈希代替加密来“保护”需还原的信息（如加密 token）
实际项目中，建议优先将敏感加解密逻辑放在服务端；前端加密宜用于提升用户体验的辅助场景（如加密本地配置、脱敏缓存、端到端消息加密的客户端环节），并始终配合 HTTPS、CSP、SRI 等纵深防御措施。
