Webhook安全风险
Webhook是API间异步通信的重要方式，但也带来独特的安全挑战：伪造请求（攻击者冒充发送方）、重放攻击（截获合法请求后重复发送）、信息泄露（Webhook URL被猜测或泄露）。
签名验证机制
HMAC签名
最常用的Webhook安全方案。发送方使用共享密钥对请求体进行HMAC-SHA256签名，放在HTTP Header中。接收方用相同密钥验证签名。GitHub、Stripe、Shopify等主流平台均使用此方案。
非对称签名
发送方使用私钥签名，接收方使用公钥验证。优势：不需要共享密钥，公钥泄露不影响安全性。Twilio和部分金融API使用此方案。
防重放攻击
- 时间戳验证：拒绝时间戳超过5分钟的请求
- 随机数（Nonce）：记录已处理的Nonce，拒绝重复
- 幂等键（Idempotency Key）：确保同一事件只处理一次
URL安全
Webhook URL应包含随机Token作为路径的一部分，增加猜测难度。配合IP白名单限制只接受来自发送方IP范围的请求。使用HTTPS确保传输安全。
接收端安全实践
异步处理
Webhook接收后立即返回200，异步处理业务逻辑。避免处理超时被发送方重试导致重复处理。使用消息队列（RabbitMQ/SQS）解耦接收和处理。
重试与死信队列
处理失败的Webhook消息进入重试队列，指数退避重试3次后进入死信队列。人工检查死信队列排查问题。
日志审计
记录所有Webhook请求（Header、Body、签名验证结果、处理结果）。敏感字段脱敏。保留至少90天供安全审计。
测试工具推荐
ngrok：本地开发环境接收Webhook。webhook.site：在线调试工具。Svix：Webhook发送平台（自动重试、签名、日志）。