后端API接口一旦暴露在公网，就相当于在互联网的黑暗森林里裸奔。你永远不知道请求是来自真实的用户，还是某个正在重放昨天截获数据包的恶意黑客。很多人以为加上HTTPS就万事大吉，但HTTPS只解决了传输层的加密和防篡改，防不住中间人把你的完整请求原封不动地再发一次。比如用户下单的接口，攻击者截获了一个支付成功的回调请求，重放一次就可能造成重复发货或者资金损失。所以，防重放攻击和签名验证不是可选项，而是API安全设计的必选项。
防重放攻击的核心思路：让每个请求都独一无二
重放攻击的本质，是服务端无法区分一个请求是第一次到达，还是被恶意重复发送。要解决这个问题，最直接的手段就是给每个请求打上唯一的标识，并且让这个标识只能使用一次。业界最成熟的方案是引入三个要素：随机数（Nonce）、时间戳（Timestamp）和签名（Signature）。这三个要素组合起来，就能构建一个相对严密的防护体系。
时间戳的作用是划定请求的有效时间窗口。客户端在发送请求时，必须带上当前的时间戳，精确到秒或者毫秒。服务端收到请求后，首先检查这个时间戳与服务器当前时间的差值。如果差值超过设定的阈值，比如60秒，就直接拒绝这个请求。这个机制能有效防止攻击者拿很久以前截获的请求来做重放，因为那些请求的时间戳早就过期了。但光有时间戳不够，因为在60秒的有效窗口内，攻击者仍然可以无脑重放。这时候就需要随机数Nonce出场。
Nonce是一个由客户端生成的随机字符串，通常结合UUID或者足够长的随机字节生成，保证在特定时间窗口内不会重复。服务端需要维护一个Nonce的缓存或数据库记录，在验证时间戳有效后，检查这个Nonce是否已经被使用过。如果发现是重复的Nonce，说明这个请求是重放的，直接丢弃。为了控制存储成本，这个Nonce记录可以设置与时间窗口相同的过期时间，比如60秒后自动清理。这样一来，时间戳和Nonce的组合，就确保了在有效时间窗口内，每个请求都是唯一的。
签名验证：确保请求的完整性与身份可信
防重放机制解决了请求的时效性和唯一性，但无法防止请求参数在传输过程中被篡改，也无法验证请求者的身份。签名验证就是用来填补这个空缺的。签名的逻辑很简单：通信双方约定一个只有自己知道的密钥（Secret Key），客户端在发送请求时，将所有参数按照特定规则排序、拼接，然后使用这个密钥生成一个哈希值，也就是签名。服务端收到请求后，用同样的规则重新计算签名，如果两个签名一致，就说明请求参数没有被篡改，并且请求者确实持有正确的密钥。
签名的生成过程有几个关键点必须严格执行。首先是参数的排序，通常要求按照参数名的ASCII码升序排列，这样可以避免因为参数顺序不同导致签名不一致。其次是拼接方式，一般格式是“参数名1=参数值1&参数名2=参数值2”，最后再拼接上密钥，然后对整个字符串进行哈希计算。常用的哈希算法包括HMAC-SHA256，它比单纯的SHA256更安全，因为引入了密钥参与哈希过程。一个典型的签名生成伪代码看起来像这样：
// 假设请求参数为 { "user_id": "123", "amount": "100", "timestamp": "1697000000", "nonce": "abc123" }
// 密钥为 "my_secret_key"
// 1. 按参数名排序后拼接
paramsString = "amount=100&nonce=abc123×tamp=1697000000&user_id=123"
// 2. 拼接密钥
signString = paramsString + "&key=my_secret_key"
// 3. 计算HMAC-SHA256签名
signature = HMAC-SHA256(signString, "my_secret_key")
// 4. 将签名加入请求参数中发送服务端验证时，需要从请求中取出签名字段，然后对剩余的参数按照完全相同的规则重新计算签名，比对两个签名值。如果一致，且时间戳和Nonce验证都通过，才认为这是一个合法请求。这里有一个容易被忽视的细节：签名计算时绝对不能包含签名字段本身，否则就陷入了循环依赖。另外，密钥的管理至关重要，绝对不能硬编码在客户端代码里。对于Web应用，密钥应该存放在服务器端的环境变量或配置中心；对于移动端，可以考虑使用动态密钥协商机制，比如通过安全通道定期下发临时令牌。
完整的安全校验流程与代码实现思路
把上述机制串联起来，一个安全的API请求校验流程应该是这样的：客户端构造请求参数，生成当前时间戳和随机Nonce，按照约定算法计算签名，将时间戳、Nonce和签名一起作为请求参数发送。服务端收到请求后，第一步检查时间戳是否在允许范围内，超出则返回错误码，比如“请求已过期”。第二步检查Nonce是否已存在，如果存在则返回“请求重复”。第三步重新计算签名，与客户端传来的签名比对，不一致则返回“签名验证失败”。只有三步全部通过，才进入实际的业务逻辑处理。
在实现层面，服务端的Nonce存储可以选用Redis这类支持自动过期的内存数据库。每次验证通过后，将Nonce作为键存入Redis，设置过期时间为时间戳允许的偏差值。这样既保证了高性能，又能自动清理过期数据，避免内存无限增长。对于分布式系统，Redis更是天然的统一存储方案，能保证不同服务节点之间的Nonce一致性。如果系统规模较小，使用数据库配合定时任务清理也未尝不可，但要考虑高并发下的性能瓶颈。
签名算法方面，强烈建议使用HMAC-SHA256而不是MD5或SHA1。MD5和SHA1已经被证明存在碰撞漏洞，在安全要求高的场景下不可靠。HMAC-SHA256的密钥长度建议至少32字节，生成时使用密码学安全的随机数生成器。另外，请求体如果是JSON格式，签名时应当对整个JSON字符串进行规范化处理，比如去除多余空格、统一键的排序，否则客户端和服务端可能因为JSON格式的微小差异导致签名不匹配。
进阶防护：请求体加密与敏感参数保护
签名验证能防止参数篡改，但参数本身还是明文传输的。虽然HTTPS加密了传输通道，但在某些高安全场景下，比如金融交易、个人隐私数据，还需要对请求体进行应用层加密。常见的做法是使用AES对称加密，密钥通过非对称加密协商。客户端用服务端的公钥加密一个临时生成的AES密钥，服务端用私钥解密拿到AES密钥，后续通信都用这个AES密钥加密请求体。这样即使HTTPS被中间人攻击破解，攻击者还需要再破解应用层的AES加密，大幅提升了攻击成本。
对于特别敏感的参数，比如密码、身份证号，即使在整个请求体中，也建议进行二次加密或者哈希处理。密码永远不要明文传输，客户端应该先进行哈希加盐处理再发送。服务端存储的也只是哈希值，这样即使数据库泄露，攻击者也无法直接拿到明文密码。这些措施与防重放、签名验证叠加起来，构成了纵深防御体系，单点被突破不会导致整体崩溃。
常见误区与落地建议
很多团队在落地这套机制时容易犯几个错误。一是时间戳阈值设置得过长，比如10分钟，这给了攻击者充足的重放窗口，Nonce的缓存压力也会成倍增加。通常30到60秒是比较合理的范围，既能容忍客户端和服务器之间的正常时钟偏差，又不会留下太大风险敞口。二是Nonce的生成不够随机，直接用自增ID或者时间戳拼接简单字符串，这在并发场景下极容易碰撞，导致正常请求被误杀。务必使用UUID v4或者密码学安全的随机数生成器。
另一个常见问题是签名时遗漏了某些关键参数。比如只签了业务参数，没签时间戳和Nonce，这会导致攻击者可以篡改时间戳和Nonce来绕过防护。签名必须覆盖所有参与验证的参数，包括时间戳和Nonce，这样才能保证整个请求的完整性。还有团队把密钥直接写在配置文件里提交到代码仓库，这是极其危险的做法。密钥应该通过环境变量注入，或者使用专门的密钥管理服务，并且定期轮换。
最后，这套安全机制对客户端的时钟同步有一定要求。如果客户端设备时间严重不准，会导致正常请求被时间戳校验拒绝。服务端可以返回服务器当前时间给客户端，客户端据此校准本地时间偏移量，在生成时间戳时进行修正。同时，服务端在时间戳校验失败时，最好在返回的错误信息中带上服务器时间，方便客户端自动调整。这样能显著提升用户体验，避免因为时钟偏差导致的请求失败。
把这些措施组合起来，你的API就具备了基本的抗重放和防篡改能力。安全设计没有一劳永逸，攻击手段在不断进化，但扎实的基础防护能过滤掉绝大部分脚本小子的自动化攻击，让你的系统从一开始就站在较高的安全基线上。
