（10805期）Webhook – 安全可靠的 webhook 收发实战指南

安全可靠的 webhook 收发实战指南 为开发者提供安全可靠的 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 下游故障：异步队列堆积需监控与告警 原始说明 Implement secure webhook receivers and senders with proper verification and reliability.