Rate Limiting & DDoS Basics for Application Developers
Limit by cost, not uniformly
Login, OTP, and payment endpoints need strict limits (5–10/min per IP + account); read APIs tolerate hundreds. Uniform limits either strangle legitimate use or leave expensive endpoints exposed. Map limits to abuse cost per endpoint.
Algorithm choice
Token bucket for bursty-legitimate traffic (checkouts), fixed window with Redis for simplicity, sliding window for precision on auth endpoints. Store counters in Redis with TTLs — in-memory limits die with horizontal scaling and forget across restarts.
DDoS layers
L3/L4 absorbed by Cloudflare/AWS Shield automatically; L7 (slow POSTs, search abuse, login floods) needs application rules — WAF managed rules plus custom rate rules plus origin shielding. Test with controlled load before sale season, not during.
Abuse signals to alert
Credential-stuffing waves (login failure spikes from rotating IPs), card-testing (small-amount payment bursts), and scraping (sustained high-rate catalogue hits). Each gets a runbook: block, challenge (Turnstile), or throttle — decided in advance, executed in minutes.
Related Articles
Preventing Supply-Chain Attacks in JavaScript Projects
Lockfiles, provenance, and minimal dependencies: hardening the npm install pipeline.
Secrets Management — From .env Chaos to Vault Discipline
Git-leaked keys, env sprawl, and rotation schedules: a maturity ladder for application secrets.
OWASP Top 10 for 2026 Web Apps — What Changed
Broken access control still leads; API abuse and supply-chain risks climb. Practical fixes per category.
Written by Security Consultant
Specialized engineering teams at Omnetra focus on writing high-performance code, ensuring API security, and optimizing layouts for client success.