给前端小白的科普，为什么说光有 HTTPS 还不够？为啥还要请求签名？

今天咱们聊个啥呢？先设想一个场景：你辛辛苦苦开发了一个前端应用，后端 API 也写得杠杠的。用户通过你的前端界面提交一个订单，比如说买1件商品。请求发出去，一切正常。但如果这时候，有个“不开眼”的黑客老哥，在你的请求发出后、到达服务器前，悄咪咪地把“1件”改成了“100件”，或者把你用户的优惠券给薅走了，那服务器收到的就是个被篡改过的“假”请求。更狠一点，如果他拿到了你某个用户的合法请求，然后疯狂重放这个请求，那服务器不就炸了？

是不是想想都后怕？别慌，今天咱就来聊聊怎么给咱们的API请求加一把“锁”，让这种“中间人攻击”和“重放攻击”无处遁形。这把锁，就是大名鼎鼎的 HMAC-SHA256 请求签名。学会了它，你就能给你的应用穿上“防弹衣”！

一、光有 HTTPS 还不够？为啥还要请求签名？

可能有机灵的小伙伴会问：“老张，咱不都有 HTTPS 了吗？数据都加密了，还怕啥？”

问得好！HTTPS 确实牛，它能保证你的数据在传输过程中不被窃听和篡改，就像给数据修了条“加密隧道”。但它主要解决的是传输层的安全。可如果：

请求签名，则是在应用层做的一道防线。它能确保：

• 
  
• 消息的完整性：数据没被篡改过。
  
• 消息的身份验证：确认消息确实是你授权的客户端发来的。
  
• 防止重放攻击：结合时间戳或 Nonce，让每个请求都具有唯一性。
  

它和 HTTPS 是好搭档，一个负责“隧道安全”，一个负责“货物安检”，双保险！

二、主角登场：HMAC-SHA256 是个啥？

HMAC-SHA256，听起来挺唬人，拆开看其实很简单：

• 
  
• HMAC：Hash-based Message Authentication Code，翻译过来就是“基于哈希的消息认证码”。它是一种使用密钥（secret key）来生成消息摘要（MAC）的方法。
  
• SHA256：Secure Hash Algorithm 256-bit，一种安全的哈希算法，能把任意长度的数据转换成一个固定长度（256位，通常表示为64个十六进制字符）的唯一字符串。相同的输入永远得到相同的输出，输入有任何微小变化，输出都会面目全非。
  

所以，HMAC-SHA256 就是用一个共享密钥 (Secret Key)，通过 SHA256 算法，给你的请求数据生成一个独一无二的“签名”。

三、签名的艺术：请求是怎么被“签”上和“验”货的？

整个流程其实不复杂，咱们用个图来说明一下：

sequenceDiagram

    participant C as 前端 (Client)

    participant S as 后端 (Server)


    C->>C: 1. 准备请求参数 (如 method, path, query, body)

    C->>C: 2. 加入时间戳 (timestamp) 和/或 随机数 (nonce)

    C->>C: 3. 将参数按约定规则排序、拼接成一个字符串 (stringToSign)

    C->>C: 4. 使用共享密钥 (Secret Key) 对 stringToSign 进行 HMAC-SHA256 运算，生成签名 (signature)

    C->>S: 5. 将原始请求参数 + timestamp + nonce + signature 一起发送给后端


    S->>S: 6. 接收到所有数据

    S->>S: 7. 校验 timestamp/nonce (检查是否过期或已使用，防重放)

    S->>S: 8. 从接收到的数据中，按与客户端相同的规则，提取参数、排序、拼接成 stringToSign'

    S->>S: 9. 使用自己保存的、与客户端相同的 Secret Key，对 stringToSign' 进行 HMAC-SHA256 运算，生成 signature'

    S->>S: 10. 比对客户端传来的 signature 和自己生成的 signature'

    alt 签名一致

        S->>S: 11. 验证通过，处理业务逻辑

        S-->>C: 响应结果

    else 签名不一致

        S->>S: 11. 验证失败，拒绝请求

        S-->>C: 错误信息 (如 401 Unauthorized)

    end

简单来说，就是：

四、Talk is Cheap, Show Me The Code!

光说不练假把式，咱们来点实在的。

前端签名 (JavaScript - 通常使用 crypto-js 库)

// 假设你已经安装了 crypto-js: npm install crypto-js
import CryptoJS from 'crypto-js';

function generateSignature(params, secretKey) {
// 1. 准备待签名数据
const method = 'GET'; // 请求方法
const path = '/api/user/profile'; // 请求路径
const timestamp = Math.floor(Date.now() / 1000).toString(); // 时间戳 (秒)
const nonce = CryptoJS.lib.WordArray.random(16).toString(); // 随机数，可选

// 2. 构造待签名字符串 (规则很重要，前后端要一致！)
// 通常会对参数名按字典序排序
const sortedKeys = Object.keys(params).sort();
const queryString = sortedKeys.map(key => `${key}=${params[key]}`).join('&');

const stringToSign = `${method}\n${path}\n${queryString}\n${timestamp}\n${nonce}`;
console.log("String to Sign:", stringToSign); // 调试用

// 3. 使用 HMAC-SHA256 生成签名
const signature = CryptoJS.HmacSHA256(stringToSign, secretKey).toString(CryptoJS.enc.Hex);
console.log("Generated Signature:", signature); // 调试用

return {

    signature,

    timestamp,

    nonce

  };

}

// --- 使用示例 ---
const mySecretKey = "your-super-secret-key-dont-put-in-frontend-directly!"; // 强调：密钥不能硬编码在前端！
const requestParams = {
userId: '123',
role: 'user'

};

const { signature, timestamp, nonce } = generateSignature(requestParams, mySecretKey);

// 实际发送请求时，把 signature, timestamp, nonce 放在请求头或请求体里
// 例如：
// fetch(`${path}?${queryString}`, {
//   method: method,
//   headers: {
//     'X-Signature': signature,
//     'X-Timestamp': timestamp,
//     'X-Nonce': nonce,
//     'Content-Type': 'application/json'
//   },
//   // body: JSON.stringify(requestBody) // 如果是POST/PUT等
// })
// .then(...)

划重点！ 上面代码里的 mySecretKey 绝对不能像这样直接写在前端代码里！这只是个演示。真正的 Secret Key 需要通过安全的方式分发和存储，比如在构建时注入，或者通过更安全的认证流程动态获取（但这又引入了新的复杂性，通常 Secret Key 是后端持有，客户端动态获取一个有时效性的 token）。对于纯前端应用，更常见的做法是后端生成签名所需参数，或者整个流程由 BFF (Backend For Frontend) 层处理。如果你的应用是 App，可以把 Secret Key 存储在原生代码中，相对安全一些。

后端验签 (Node.js - 使用内置 crypto 模块)

const crypto = require('crypto');

function verifySignature(requestData, clientSignature, clientTimestamp, clientNonce, secretKey) {
// 0. 校验时间戳 (例如，请求必须在5分钟内到达)
const serverTimestamp = Math.floor(Date.now() / 1000);
if (Math.abs(serverTimestamp - parseInt(clientTimestamp, 10)) > 300) { // 5分钟窗口
console.error("Timestamp validation failed");
return false;

  }

// (可选) 校验 Nonce 防止重放，需要存储已用过的 Nonce，可以用 Redis 等
// if (isNonceUsed(clientNonce)) {
//   console.error("Nonce replay detected");
//   return false;
// }
// markNonceAsUsed(clientNonce, clientTimestamp); // 标记为已用，并设置过期时间

// 1. 从请求中提取参与签名的参数
const { method, path, queryParams } = requestData; // 假设已解析好

// 2. 构造待签名字符串 (规则必须和客户端完全一致！)
const sortedKeys = Object.keys(queryParams).sort();
const queryString = sortedKeys.map(key => `${key}=${queryParams[key]}`).join('&');

const stringToSign = `${method}\n${path}\n${queryString}\n${clientTimestamp}\n${clientNonce}`;
console.log("Server String to Sign:", stringToSign);

// 3. 使用 HMAC-SHA256 生成签名
const expectedSignature = crypto.createHmac('sha256', secretKey)

                               .update(stringToSign)

                               .digest('hex');
console.log("Server Expected Signature:", expectedSignature);
console.log("Client Signature:", clientSignature);

// 4. 比对签名 (使用 crypto.timingSafeEqual 防止时序攻击)
if (clientSignature.length !== expectedSignature.length) {
return false;

  }
return crypto.timingSafeEqual(Buffer.from(clientSignature), Buffer.from(expectedSignature));

}

// --- Express 示例中间件 ---
// app.use((req, res, next) => {
//   const clientSignature = req.headers['x-signature'];
//   const clientTimestamp = req.headers['x-timestamp'];
//   const clientNonce = req.headers['x-nonce'];
//   // 实际项目中，secretKey 应该从环境变量或配置中读取
//   const API_SECRET_KEY = process.env.API_SECRET_KEY || "your-super-secret-key-dont-put-in-frontend-directly!";

//   // 构造 requestData 对象，包含 method, path, queryParams
//   // 注意：如果是 POST/PUT 请求，请求体 (body) 通常也需要参与签名
//   // 且 body 如果是 JSON，建议序列化后参与签名，而不是原始对象
//   const requestDataForSig = {
//     method: req.method.toUpperCase(),
//     path: req.path,
//     queryParams: req.query, // 对于GET；POST/PUT可能还需包含body
//     // bodyString: req.body ? JSON.stringify(req.body) : "" // 如果body参与签名
//   };

//   if (!verifySignature(requestDataForSig, clientSignature, clientTimestamp, clientNonce, API_SECRET_KEY)) {
//     return res.status(401).send('Invalid Signature');
//   }
//   next();
// });

五、细节是魔鬼：实施过程中的注意事项

六、HMAC-SHA256 vs. 其他方案？

HMAC-SHA256 更侧重于请求本身的完整性和来源认证，而 JWT 更侧重于用户身份的认证和授权。它们可以结合使用。

好啦，今天关于 HMAC-SHA256 请求签名的唠嗑就到这里。这玩意儿看起来步骤多，但一旦理解了原理，实现起来其实就是细心活儿。给你的 API 加上这把锁，晚上睡觉都能踏实点！

我是老码小张，一个喜欢研究技术原理，并且在实践中不断成长的技术人。希望今天的分享对你有帮助，咱们下回再聊！欢迎大家留言交流你的看法和经验哦！