A webhook endpoint that receives WhatsApp messages from Meta is exposed to the public internet. HMAC signature verification proves the payload came from Meta, but it does not protect against replay attacks, rate-based amplification, or attackers who obtain the app secret.
Key Analysis
HMAC verification proves the payload was signed with the app secret — but not that it wasn't replayed from an earlier legitimate request.
A webhook endpoint without rate limiting is a potential amplification target: an attacker can flood the endpoint with valid-looking requests (signed with a stolen secret) to exhaust your processing capacity.
WAF rules for webhook endpoints should enforce: POST-only, Meta IP range allowlisting, Content-Type validation, and body size limits.
Risk Signals
Webhook endpoints with no rate limiting beyond what HMAC verification provides.
No timestamp validation on incoming webhooks — making replay attacks trivially feasible.
App secret stored in version control, environment variable without secret management, or accessible to www-data in plaintext.
Action Items
Implement timestamp validation: reject webhooks with a timestamp more than 5 minutes old.
Rate limit the webhook endpoint at the Nginx layer: max 100 requests/minute from any single IP.
Store the Meta app secret in a dedicated secret management system — never in code or environment files readable by www-data.