Limiting abuse: rate limiting / throttling
Even if a request is legitimate, a thousand per second from the same client
can take down your service or brute-force passwords. Rate
limiting counts the requests per key (IP, user, API key) within a
time window and, when the maximum is exceeded, rejects them with the status
code 429 Too Many Requests:
// pseudocode of a per-window limiter
if (count(key) >= MAX) {
return res.status(429).json({ error: "Too many requests" });
}
Throttling is the variant that slows down instead of cutting off abruptly.
ALWAYS validate on the server
Validation on the client (in the browser) improves the experience, but it is not
security: the client is under the attacker's control, who can bypass the
form and call your API directly with curl.
Never trust the client. Every input that reaches the server is validated again on the server: types, ranges, lengths, format and business rules. Client validation is convenience; server validation is the real barrier.
High-level defenses: captcha and WAF
- A captcha distinguishes humans from bots and curbs mass registration, credential stuffing and spam.
- A WAF (Web Application Firewall) sits in front of your application and inspects the traffic to block known attack patterns (injection, scraping, DDoS) before they reach your code.
They are additional layers: they complement, not replace, the validation and escaping inside your application.