HTML5需借助Web Crypto API或第三方库实现HMAC消息认证，关键包括密钥安全分发、统一UTF-8编码与规范化签名原文构造、前后端哈希算法及密钥预处理逻辑严格对齐。
HTML5本身不内置HMAC算法，但可通过JavaScript调用标准加密库（如Web Crypto API或第三方库）结合HMAC实现端到端的消息认证。关键在于密钥安全保管、哈希函数选型、数据标准化处理，以及前后端协同验证逻辑。
使用Web Crypto API原生支持HMAC
现代浏览器普遍支持Web Crypto API，它提供标准化、安全的HMAC计算能力，无需引入外部依赖：
- 调用
crypto.subtle.importKey()将密钥导入为JsonWebKey格式，类型设为"raw"，算法指定{ name: "HMAC", hash: "SHA-256" } - 用
crypto.subtle.sign()生成HMAC值，输入为UTF-8编码后的消息（需先用new TextEncoder().encode(message)转换） - 输出为ArrayBuffer，建议转为base64或十六进制字符串便于传输和比对
- 注意：密钥不可硬编码在前端，应由后端动态下发（如短期有效的JWT签名密钥），或通过安全上下文（如HTTPS + Secure Cookie）协商
消息格式与预处理必须统一
HMAC对输入字节流敏感，前后端若对消息的编码、截断、序列化方式不一致，会导致验签失败：
- 前端发送前，对JSON对象先
JSON.stringify()，再去除空格（避免换行/缩进差异） - 时间戳、随机数（nonce）等字段需明确约定是否参与签名，且格式固定（如ISO 8601时间字符串、16位小写hex nonce）
- 推荐构造规范化签名原文：按字段名ASCII升序拼接
key=value，用&连接（类似OAuth 1.0a），避免JSON键序不确定性 - 所有字符串统一用UTF-8编码，禁止使用
unescape或encodeURI等非标准编码
规避常见前端安全隐患
HTML5环境缺乏服务端隔离能力，密钥管理和签名过程易被逆向或劫持：
立即学习“前端免费学习笔记（深入）”；
- 绝不将长期密钥（如API Secret）暴露在前端代码、localStorage或URL中
- 敏感操作（如支付签名）应由前端生成待签数据+nonce，交由后端完成HMAC计算并返回签名结果
- 若必须前端签名（如无状态API调用），采用短期令牌机制：后端签发含过期时间的
session_key，前端仅用其生成单次HMAC - 启用Subresource Integrity（SRI）校验所引用的加密库完整性，防止CDN劫持篡改
crypto-js等第三方脚本
与后端验签逻辑严格对齐
前端生成的HMAC必须能被后端无歧义还原验证，双方需同步以下细节：
- 哈希算法完全一致（如都用HmacSHA256，而非SHA-256裸哈希）
- 密钥预处理规则相同：密钥长度超过哈希块大小（SHA-256为64字节）时，是否先做一次SHA-256哈希；不足时是否左补零
- ipad（0x36×64）与opad（0x5c×64）的生成逻辑、拼接顺序、字节序保持一致
- 推荐后端使用标准库（如Java的
javax.crypto.Mac、Node.js的crypto.createHmac）而非手写实现，降低偏差风险
