为开发者提供安全可靠的 webhook 收发完整方案，涵盖签名验证、防重放、幂等性、重试策略等关键安全实践。
说明：
## 核心用法
本技能专注于 webhook 的安全实现，分为**接收端**与**发送端**两大场景。
### 接收端最佳实践
– **签名验证**：必须使用 HMAC-SHA256 验证请求真实性，使用原始 body 字节避免 JSON 重排序导致验签失败，采用恒定时间比较防止时序攻击
– **防重放攻击**：验证时间戳（拒绝 >5 分钟旧请求），结合签名确保不可伪造
– **幂等性处理**：通过 event ID 去重存储（建议保留 24-72 小时），处理逻辑本身也需幂等
– **快速响应**：先返回 200/202，再异步处理，避免发送方超时重试
– **错误码规范**：2xx 成功、4xx 永久失败、5xx 临时失败触发重试
### 发送端最佳实践
– **签名生成**：时间戳 + 版本化签名头（如 `t=xxx,v1=sig`），提供多语言验签示例
– **重试策略**：指数退避（1min→5min→30min→2h→8h），区分 4xx/5xx 响应
– **超时控制**：5-10 秒超时，禁止无限重定向，强制 HTTPS 证书验证
### 事件设计规范
包含事件类型、ISO 8601 时间戳、完整资源数据或 ID、API 版本号，便于接收方过滤与演进。
## 显著优点
– 覆盖完整生命周期：从设计、开发到运维监控的全链路指导
– 安全优先：将签名验证、防重放、幂等性作为强制要求而非可选
– 工程可落地：提供具体参数（超时秒数、退避间隔、保留天数）和代码模式
– 双向视角：同时指导发送方与接收方，减少对接摩擦
## 潜在局限性
– 未涉及特定云服务商（AWS SNS、Stripe、GitHub）的专有实现差异
– 缺少大规模高并发场景下的队列选型建议（Kafka vs RabbitMQ vs 云队列）
– 对 WebSocket/SSE 等替代方案无对比分析
## 适合人群
– 构建 SaaS 平台需对外提供 webhook 集成的后端工程师
– 对接第三方服务需实现接收端的安全开发者
– 负责 webhook 系统架构审查的技术负责人
## 常规风险
– **密钥泄露**：共享 secret 需轮换机制，避免硬编码
– **时钟不同步**：NTP 配置不当导致合法请求被拒或重放攻击穿透
– **存储爆炸**：event ID 去重表无限增长需设置 TTL
– **下游故障**：异步队列堆积需监控与告警
会员专属
