Webhook 请求头签名怎么校验？拆解微信支付的“四张证件”防重放实战
Webhook 请求头签名校验是通过比对 HTTP 头中的时间戳、随机数及内容哈希，验证数据完整性与防重放攻击的自动化安全流程。
为什么“免签”不是跳过验证？厘清核心逻辑
免签支付仅指用户端免密，服务端仍需严格校验回调真实性与完整性，任何跳过验证的行为都会导致资金安全风险。
别被“免签支付”这个词骗了，它绝不意味着你可以对回调请求睁只眼闭只眼。所谓的“免签”，只是指用户端无需输入密码，服务端却必须完成一道更严格的隐形安检。现有官方材料不支持任何“跳过验证”的解释，相反，它们都在强调真实性与完整性的校验是铁律[1]。
三大主流平台的验签共识
不管你是对接 Stripe、PayU 还是微信支付，底层逻辑是一致的：接收方必须先确认“你是谁”以及“数据有没有被改过”，才能放心返回响应或处理业务。
| 平台 | 安全机制特点 | 关键风险点 |
|---|---|---|
| Stripe | 强制通过签名密钥验证每一个 Webhook 请求 | 缺失签名直接视为非法，无缓冲余地 |
| PayU | 包含 hash 字段暗示校验，但算法细节模糊 |
文档证据强度弱，需自行推导流程 |
| 微信支付 | 绑定 HTTP 头（序列号、时间戳）与私钥闭环 | 头部信息缺失或证书错配导致全盘失败 |
| Adyen | 采用 HMAC-SHA256 对特定字段组合签名，依赖共享密钥 | 密钥轮换期间若未同步更新本地缓存，会导致批量拒单 |
这三类材料共同指向一个结论：快速应答不等于放弃安全。你必须先验证来源和完整性，再给平台返回”200 OK”，最后再异步去更新订单状态。缺乏完整代码或字段表的通用文档不能直接套用，务必依据单一信源进行复核，否则就是拿资金安全在赌博[1]。值得注意的是，Adyen 等新兴平台虽然也使用类似机制，但其密钥轮换策略往往比传统银行系更频繁，这要求开发者在本地缓存管理上预留更短的失效窗口，否则极易出现“明明配置正确却突然全部验签失败”的被动局面。
Webhook 请求头签名怎么校验：拆解微信支付的四大关键要素
微信支付回调验签需依次查验请求头中的序列号、签名算法、签名值及公钥指纹四要素，缺一不可才能确认为合法请求。
别把“免签”当成不用核对身份。微信支付回调时，你的服务器必须像保安一样，先查验对方递来的四张“证件”，确认无误后才能放行。这四张证件都藏在 HTTP 请求头里，缺一不可。
HTTP 头中的安全防线
第一张证件是 Wechatpay-Serial。它不是密钥本身，而是你本地公钥证书的身份证序列号[2]。拿到这个号码，你才能从自己的证书库中精准提取出对应的公钥。如果拿错公钥，后续所有计算都会失败。第二张证件是 Wechatpay-Signature。这是支付平台用私钥对整段报文生成的数字指纹[2]。你需要用刚才找到的公钥去解密这个指纹，再对比自己算出的指纹是否一致。只要有一个字节被篡改，或者来源不对，这两个指纹就对不上。
光有身份和指纹还不够，还得防住“旧戏重演”。第三张和第四张证件分别是 Wechatpay-Timestamp（时间戳）和 Wechatpay-Nonce（随机数）。这两者组合起来，构成了当前请求的唯一指纹。时间戳标记了请求发出的瞬间，随机数则确保了即使同一秒内发起两次请求，内容也完全不同[2]。缺少其中任何一项，系统就无法判断这是否是一次恶意的重放攻击。
官方文档强制规定，商户必须在收到请求后的 5 秒内完成上述验签并返回应答[2]。这意味着你的代码不能先处理复杂的业务逻辑再回头验签，而必须先做这道“安检门”。你可以将验签后的业务逻辑（如更新订单状态）放入异步队列处理，但核心的身份核验必须在 5 秒窗口期内完成。一旦超时或头部信息缺失，整个验证链条即刻断裂，你必须直接拒绝请求。
实战步骤：如何利用时间戳与内容比对防止重放攻击
防止重放攻击需先校验时间戳时效性与随机数唯一性，再比对主体内容哈希，确保数据未被篡改且非旧消息恶意重发。
收到回调请求后，别急着改订单状态。先花五秒钟把“真货”和“假货”筛出来，这是防止丢单的第一道防线。只要按顺序走完这四步，你就能确保数据既没被篡改，也不是旧消息的恶意重发。
第一步：掐表检查时间戳
拿到请求后，第一件事是看 Wechatpay-Timestamp。微信支付只给 5 秒的有效期[2]。如果当前时间与头里的时间差超过 5 秒，直接拒绝。这招专治“重放攻击”，黑客拿不到你的私钥，只能偷录旧数据包，一旦过期就是废纸。
- 合格标准：计算当前时间与 Timestamp 的差值，差值必须小于等于 5 秒，超时请求直接返回 HTTP 400 并终止流程。
第二步：核对随机数（Nonce）
时间戳能防旧包，但防不住同一秒内的重复发送。你需要提取 Wechatpay-Nonce 字段，并在本地缓存里查一下这个组合是否出现过。如果同一个时间戳配同一个随机数再次出现，说明有人在刷接口，直接拦截。
- 缓存设计建议：使用内存数据库（如 Redis）或本地 Map 存储，Key 格式为
Timestamp_Nonce，设置极短的过期时间（如 10 秒），用完即焚，避免内存泄漏。
第三步：重组字符串与解密比对
前两步只是过滤垃圾，真正的验签在第三步。你需要按规范拼接待签名字符串：将 HTTP 头中的方法、URL、时间戳、随机数和请求体 JSON 按特定规则连起来。接着，用 Wechatpay-Serial 找到对应的公钥，对 Wechatpay-Signature 进行解密验证[2]。这一步就像把信封拆开，核对里面的字是不是你亲手写的。
- 关键操作点：严格遵循官方文档的拼接顺序（通常包含 Method + URL + Body），确保使用的公钥与 Serial 号完全匹配，校验失败立即抛出异常，不执行后续逻辑。
第四步：确认无误后再动业务
只有当签名验证通过，且数据完整性得到确认，你才能认为来源可信。此时再返回成功的 HTTP 响应给支付平台，随后异步处理订单更新、发货等业务逻辑[1][3]。记住，快速应答是为了让支付通道不超时，但真正的业务动作必须在安全校验之后。
- 验收清单：时间戳在 5 秒窗口内；Nonce 未在当前周期重复；签名解密比对一致；已返回成功响应码；业务逻辑进入异步队列。
完成这四步，你的系统就筑起了防重放的高墙。数据没丢，单子没错，这才是“免签”背后的真实安全逻辑。
常见陷阱与应对：确保回调验签不丢单
在官方规定的五秒超时窗口内完成签名校验是防丢单核心，随后应将复杂业务逻辑异步执行以兼顾安全性与响应速度。
别为了抢那几毫秒的响应速度而跳过验签，否则你根本无法区分真假回调。在官方规定的 5 秒超时窗口内，你的首要任务是完成签名校验[2]。一旦确认请求合法，立即返回成功响应，随后再将复杂的订单状态更新、库存扣减等逻辑扔进后台队列异步执行，这才是既安全又高效的写法[2]。
另一个高频雷区是证书版本错配。请严格核对本地存储的公钥证书是否与 Wechatpay-Serial 头中的序列号一致，证书过期或版本不对都会直接导致验签失败[1]。由于缺乏通用的代码模板能覆盖所有平台细节，实施时务必死磕当前平台的单一官方文档，切勿盲目套用其他支付渠道的逻辑[3]。
本章行动清单
- [ ] 5 秒内先验签，后应答，严禁省略步骤
- [ ] 业务逻辑（如改单）全部放入异步队列处理
- [ ] 每次收到回调前，检查本地证书 Serial 是否匹配
常见问题解答 (FAQ)
Q: 如果我在 5 秒内完成了验签但业务处理超时了怎么办？ A: 只要在 5 秒窗口内返回了 HTTP 200 状态码，微信支付就会认为请求成功。后续的订单更新、库存扣减等耗时操作可以放在异步线程或消息队列中慢慢跑，不会阻塞支付通道的响应。
Q: 为什么我的验签一直失败，提示签名不匹配？
A: 最常见的原因是公钥证书版本不对。请仔细检查 Wechatpay-Serial 头中的序列号是否与你本地加载的证书完全一致。有时候证书更新后，旧的 Serial 号就失效了，必须重新下载最新证书。
Q: 如何彻底杜绝重放攻击？ A: 单纯的时间戳校验不够，必须配合 Nonce（随机数）机制。将时间戳和随机数的组合存入 Redis 并设置短时效（如 10 秒），每次请求先查缓存，如果存在则直接丢弃，这样即使是同一秒内的重复请求也能被拦截。