Rate limiting beperkt hoeveel requests een client in een bepaald tijdvenster mag doen. Je past het toe op meerdere lagen omdat elke laag iets anders ziet, en je identificeert de misbruiker via wat dan ook wat de aanvaller uniek maakt.
Rate limiting beperkt hoeveel requests een client in een bepaald tijdvenster mag doen. Je past het toe op meerdere lagen omdat elke laag iets anders ziet, en je identificeert de misbruiker via wat dan ook wat de aanvaller uniek maakt.
429 Too Many Requests met Retry-After zodat clients netjes terugtrekken in plaats van te blijven hammeren.# Define a shared-memory zone keyed by client IP.
# rate=10r/s = the steady refill rate (token bucket).
limit_req_zone $binary_remote_addr zone=api:10m rate=10r/s;
server {
location /api/ {
# burst=20: allow a short spike of 20 queued requests
# nodelay: serve the burst immediately instead of spacing it out
limit_req zone=api burst=20 nodelay;
# Return 429 (not the default 503) so clients see a rate-limit signal
limit_req_status 429;
proxy_pass http://backend;
}
}
Hier laadt elk IP zich opnieuw op met 10 requests/seconde, mag tot 20 bursten, en alles erop volgend krijgt een 429.
Rate limiting is je goedkoopste, altijd-aan verdediging tegen Layer 7 floods, credential stuffing, en ontspoorde scrapers. Door het te stratificeren (edge voor volume, proxy voor de origin, app voor bedrijfslogica) en het correct aan te sleutelen, stop je misbruikers terwijl echte gebruikers — en legitieme bursts — ongehinderd passeren. Het instellen van limieten op basis van echte baselines zorgt ervoor dat het niet een storing wordt die je jezelf aangedaan hebt.