Summary
Nothing currently throttles how fast a single WhatsApp sender (or the webhook overall) can trigger backend work — a compromised or malicious sender could hammer the send/swap paths.
Description
Implement a Redis-backed token-bucket or sliding-window limiter keyed by sender phone number, with separate (tighter) limits for financial commands (send/swap/deploy/export) vs. read-only ones (balance/address/help).
On limit exceeded, reply with a clear rate-limited message rather than silently dropping, and still ACK the webhook 200 quickly.
Add a global/IP-level limit on the webhook route itself as defense in depth against non-Meta traffic hitting the endpoint.
Add tests asserting the limiter trips at the configured threshold and resets correctly.
Deliverables
- Per-sender rate limiter with tiered limits
- Webhook-level rate limiting
- Tests for trip/reset behavior
Dependencies
Summary
Nothing currently throttles how fast a single WhatsApp sender (or the webhook overall) can trigger backend work — a compromised or malicious sender could hammer the send/swap paths.
Description
Implement a Redis-backed token-bucket or sliding-window limiter keyed by sender phone number, with separate (tighter) limits for financial commands (send/swap/deploy/export) vs. read-only ones (balance/address/help).
On limit exceeded, reply with a clear rate-limited message rather than silently dropping, and still ACK the webhook 200 quickly.
Add a global/IP-level limit on the webhook route itself as defense in depth against non-Meta traffic hitting the endpoint.
Add tests asserting the limiter trips at the configured threshold and resets correctly.
Deliverables
Dependencies