Rate limiting at the app or reverse proxy can cap request volume per IP or key. It helps with application-layer attacks; for volumetric attacks you need upstream scrubbing. Combine with WAF and DDoS protection.
Application-layer attacks
- What they are: High volume of seemingly valid HTTP(S) requests (e.g. many GET/POST to expensive endpoints). Goal is to exhaust your app, DB, or bandwidth.
- Rate limiting: Cap requests per IP, per API key, or per user. At the app (middleware) or at the reverse proxy/edge. Returns 429 when over limit; slows or blocks the attacker while allowing legitimate users (within limits).
- Tuning: Set limits high enough for real users and low enough to cap abuse. Use tiers (e.g. anonymous vs authenticated). Combine with WAF rules (block known bad patterns).
Volumetric attacks
- What they are: Huge traffic floods (e.g. UDP, SYN, or amplified). Goal is to saturate your link or the provider's link. No amount of app-level rate limiting will help—traffic never reaches your server or overwhelms the pipe.
- Upstream scrubbing: You need the provider or a DDoS mitigation service to scrub traffic before it hits you. They absorb or filter the flood and forward only legitimate traffic. Tier-III or specialized DDoS providers often offer this.
- Plan: Know whether your host includes DDoS mitigation and what the process is (automatic vs on-demand). Have a contact and runbook.
Combine layers
- Edge/WAF: Block or rate-limit at the edge (CDN, WAF, load balancer). Reduces load that reaches your app.
- App: Per-user or per-key limits; protect expensive endpoints and auth. Return 429 and Retry-After.
- Network: Rely on provider or DDoS service for volumetric. You cannot fix a 100 Gbps flood at the app.
Summary
Rate limiting helps with application-layer DDoS; cap requests per IP/key at app or proxy. For volumetric attacks you need upstream scrubbing (provider or DDoS service). Combine with WAF and have a DDoS response plan.
