golang如何实现Webhook签名验证_golang Webhook签名验证实现技巧-Golang-PHP中文网

Webhook签名验证需严格遵循三要点：正确解析签名头（剥离前缀或提取字段）、仅一次读取原始payload并复用、使用hmac.Equal恒定时间比对；必须校验时间戳防重放，且密钥与字节一致性须实测验证。

golang如何实现webhook签名验证_golang webhook签名验证实现技巧

Webhook 签名验证不是“加个 HMAC-SHA256 就完事”，关键在于签名生成逻辑、时间戳容差、编码一致性这三点对不上，401 Unauthorized 或 signature mismatch 就会反复出现。

GitHub、Stripe、Slack 等平台签名头命名不统一，且值格式有前缀（如 sha256=...），直接用 req.Header.Get("X-Hub-Signature-256") 拿到的是带前缀字符串，不剥离就无法比对。

必须用 strings.TrimPrefix 剥离前缀，例如：sig := strings.TrimPrefix(req.Header.Get("X-Hub-Signature-256"), "sha256=")
部分服务（如 Stripe）用 Stripe-Signature，其值是逗号分隔的多个字段（t=171... , v1=..., v0=...），需先按 , 拆分再提取 v1 字段
空值或缺失头要提前返回 400，避免后续 panic；建议用 if sig == "" { http.Error(w, "missing signature", http.StatusBadRequest); return }

req.Body 是单次读取流，若你在日志里先 io.ReadAll(req.Body) 打印调试，后面再读一次——第二次读到的就是空字节，签名必然失败。

正确做法：只读一次，把结果存为 payload 变量，后续签名计算和业务逻辑都复用它
如果需要保留 req.Body 给下游 handler（比如用 http.StripPrefix 后转给 Gin），得用 io.NopCloser(bytes.NewReader(payload)) 重建一个可重读的 Body
别用 req.FormValue 或 req.PostForm 解析 payload —— Webhook 多数是 application/json 或 application/x-www-form-urlencoded，但签名是对原始字节算的，不是对解析后的 map

直接用 == 比较会导致时序攻击风险，Go 标准库明确要求用 hmac.Equal 做恒定时间比对。而且 hmac.Sum().Sum(nil) 返回的是带哈希前缀的字节，而签名头是 hex 编码字符串，必须统一转成 []byte 再比。

Golang Uber Dig

使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等

下载

计算本地签名：用 hmac.New + sha256.New，写入 payload，再用 hex.EncodeToString(sum.Sum(nil)) 得到字符串
将 header 中提取的签名字符串用 hex.DecodeString 转成 []byte
最后用 hmac.Equal(localSigBytes, headerSigBytes) 判断，返回 bool
注意：有些平台（如 Discord）签名是 base64 编码，不是 hex，解码要用 base64.StdEncoding.DecodeString

多数 Webhook（GitHub、Stripe）在签名 payload 外额外附带时间戳（如 X-Hub-Signature-256 同级的 X-Hub-Timestamp），不校验它等于裸奔。

从 header 读出时间戳后，用 strconv.ParseInt 转成 int64，再用 time.Unix(timestamp, 0) 构造时间
与 time.Now().UTC() 比较，容差建议设为 5 分钟（5 * time.Minute），太长易被重放，太短可能因服务器时钟不同步误杀
如果时间戳早于当前时间减去容差，或晚于当前时间加容差，直接拒绝 —— 不要只 warn，要 http.Error(w, "...", http.StatusForbidden)
别忘了：时间戳本身是签名的一部分（如 GitHub 是 timestamp + payload 拼接后签名），所以校验顺序必须是「先验时间戳有效性 → 再验签名」