Rate-limiting

Rate-limiting is een beveiligingstechniek die het aantal verzoeken controleert dat een gebruiker, IP-adres of applicatie mag doen binnen een vastgestelde tijdsperiode. Wanneer het limiet wordt overschreden, worden verdere verzoeken geblokkeerd of vertraagd. Het is een van de meest effectieve verdedigingsmechanismen tegen brute force-aanvallen, credential stuffing en bepaalde vormen van DDoS-aanvallen. Door het tempo van inkomende verzoeken te reguleren, bescherm je je servers, API's en applicaties tegen overbelasting en misbruik.

Rate-limiting wordt breed ingezet bij webapplicaties, API's, loginpagina's en e-mailservers. Grote cloudproviders als Cloudflare, AWS en Akamai bieden ingebouwde rate-limiting functionaliteit aan. Het principe is eenvoudig maar krachtig: door een maximum te stellen aan het aantal toegestane verzoeken, maak je geautomatiseerde aanvallen onpraktisch. Een aanvaller die duizenden wachtwoorden per seconde wil proberen, wordt teruggebracht tot enkele pogingen per minuut, wat de aanval in de praktijk onhaalbaar maakt.

Hoe werkt rate-limiting?

Rate-limiting werkt door het bijhouden van het aantal verzoeken per identificator, meestal een IP-adres, API-key of gebruikersaccount, binnen een bepaald tijdvenster. Wanneer het maximum wordt bereikt, ontvangt de afzender een HTTP 429 Too Many Requests-respons. Na het verstrijken van het tijdvenster wordt de teller gereset en kan de gebruiker weer verzoeken doen.

Er zijn verschillende algoritmen voor rate-limiting, elk met eigen kenmerken. Het token bucket-algoritme kent elke client een emmer met tokens toe. Elk verzoek verbruikt een token en tokens worden op een vast tempo aangevuld. Dit staat gecontroleerde bursts toe terwijl het gemiddelde gebruik beperkt blijft. Het leaky bucket-algoritme verwerkt verzoeken op een vast tempo, wat voorspelbare serverbelasting oplevert maar legitiem burstverkeer kan weigeren.

Het sliding window-algoritme combineert de voordelen van beide. In plaats van een vast tijdvenster gebruikt het een glijdend venster dat continu meeschuift, waardoor het nauwkeuriger is in het beperken van verzoeken op de grens van tijdvensters. Het fixed window-algoritme is eenvoudiger maar kan pieken toestaan op de overgang tussen vensters, wat aanvallers kunnen exploiteren.

Moderne rate-limiting-implementaties gaan verder dan simpele IP-based limieten. Ze passen limieten toe op basis van gebruikersaccounts, API-keys, geografische locatie en zelfs het type verzoek. Een ingelogde gebruiker krijgt een hoger limiet dan een anonieme bezoeker. API-calls naar gevoelige endpoints zoals login of wachtwoordherstel krijgen strengere limieten dan reguliere paginaverzoeken.

Web application firewalls (WAF's) bieden geavanceerde rate-limiting met regels die je kunt configureren per URL-pad, HTTP-methode en request header. Cloudflare biedt bijvoorbeeld granulaire rate-limiting met ondersteuning voor aangepaste regels, API-specifieke limieten en automatische escalatie bij verdacht gedrag.

Hoe implementeer je rate-limiting?

De implementatie hangt af van je architectuur. Voor webapplicaties kun je rate-limiting implementeren op meerdere niveaus: op de web application firewall, op de reverse proxy, in de applicatiecode of op de API-gateway. De meest effectieve aanpak combineert meerdere niveaus voor defense in depth.

Op infrastructuurniveau configureer je rate-limiting in je reverse proxy of load balancer. Nginx biedt de limit_req-module voor HTTP rate-limiting. Apache heeft mod_ratelimit. Voor cloudgebaseerde omgevingen bieden AWS API Gateway, Google Cloud Armor en Azure Front Door ingebouwde rate-limiting die automatisch schaalt met je verkeer.

Op applicatieniveau implementeer je rate-limiting via middleware of libraries. In Node.js is express-rate-limit een veelgebruikte library. In Python biedt Django Ratelimit dezelfde functionaliteit. Voor API's is het standaardpraktijk om rate-limit headers mee te sturen in de respons, zodat clients weten hoeveel verzoeken ze nog mogen doen: X-RateLimit-Limit, X-RateLimit-Remaining en X-RateLimit-Reset.

Bij het kiezen van limieten is balans essentieel. Te strenge limieten blokkeren legitieme gebruikers. Te ruime limieten bieden onvoldoende bescherming. Begin met het analyseren van je normale verkeerspatronen. Stel limieten in die twee tot drie keer hoger liggen dan je piekverkeer voor normale gebruikers. Monitor vervolgens of legitieme gebruikers worden geblokkeerd en pas de limieten aan op basis van data.

Implementeer gedifferentieerde limieten per endpoint. Loginpagina's en wachtwoordherstel-endpoints verdienen strikte limieten, bijvoorbeeld vijf pogingen per minuut. Reguliere paginaverzoeken kunnen ruimere limieten hebben, bijvoorbeeld honderd verzoeken per minuut. API-endpoints voor betalingen of gevoelige data krijgen specifieke limieten afgestemd op verwacht gebruikspatroon.

Best practices voor rate-limiting

Pas rate-limiting toe op basis van meerdere identificatoren, niet alleen IP-adressen. Aanvallers gebruiken botnets met duizenden IP-adressen om IP-based limieten te omzeilen. Door limieten te combineren op IP-adres, gebruikersaccount en API-key, maak je het significant moeilijker om je verdediging te omzeilen. Gebruik CAPTCHA's als aanvullende maatregel wanneer rate limits worden bereikt.

Geef duidelijke foutmeldingen wanneer een limiet wordt bereikt. Een HTTP 429-respons met een Retry-After header vertelt de client wanneer hij opnieuw mag proberen. Dit voorkomt dat legitieme clients in een retry-loop raken die het probleem verergert. Documenteer je rate limits in je API-documentatie zodat ontwikkelaars hun applicaties hierop kunnen inrichten.

Monitor je rate-limiting actief. Log alle gevallen waarin limieten worden bereikt en analyseer patronen. Plotselinge pieken in rate-limited verzoeken kunnen wijzen op een aanval in uitvoering. Integreer je rate-limiting logs met je SIEM-systeem voor correlatie met andere securitygebeurtenissen. Stel alerting in voor ongebruikelijke patronen.

Overweeg adaptieve rate-limiting die automatisch strenger wordt bij verdacht gedrag. Als een IP-adres herhaaldelijk het limiet bereikt, kan het systeem automatisch het limiet verlagen of het IP-adres tijdelijk blokkeren. Volgens Akamai biedt aggregated rate-limiting extra bescherming tegen grootschalige aanvallen door verkeerspatronen over meerdere bronnen te analyseren.

Test je rate-limiting regelmatig. Voer load tests uit om te verifieren dat je limieten correct werken onder druk. Controleer of bypasses mogelijk zijn via alternatieve endpoints of HTTP-methoden. Zorg dat rate-limiting niet omzeild kan worden door headers te manipuleren, bijvoorbeeld door het spoofen van X-Forwarded-For headers. Valideer dat je backend de werkelijke client-IP gebruikt en niet een gemanipuleerde headerwaarde.

Gebruik rate-limiting als onderdeel van een bredere verdedigingsstrategie. Combineer het met firewall-regels, DDoS-bescherming en bot detection voor een robuuste bescherming tegen geautomatiseerde aanvallen. Rate-limiting alleen stopt geen geavanceerde aanvaller, maar als onderdeel van defense in depth maakt het aanvallen significant duurder en moeilijker.

Veelgestelde vragen over rate-limiting

Kan rate-limiting DDoS-aanvallen stoppen?

Rate-limiting biedt bescherming tegen layer 7 (applicatielaag) DDoS-aanvallen door het aantal verzoeken per bron te beperken. Tegen volumetrische layer 3/4 DDoS-aanvallen is rate-limiting alleen niet voldoende. Daarvoor heb je aanvullende DDoS-mitigatie nodig van je hostingprovider of een CDN als Cloudflare.

Wat is het verschil tussen rate-limiting en throttling?

Rate-limiting blokkeert verzoeken die het limiet overschrijden met een HTTP 429-respons. Throttling vertraagt verzoeken in plaats van ze te blokkeren, waardoor ze alsnog worden verwerkt maar op een lager tempo. In de praktijk worden de termen vaak door elkaar gebruikt, maar het onderscheid is relevant bij het ontwerpen van je API-strategie.

Hoe voorkom je dat rate-limiting legitieme gebruikers blokkeert?

Stel limieten in op basis van je werkelijke verkeerspatronen. Gebruik gedifferentieerde limieten per gebruikerstype en endpoint. Implementeer whitelisting voor bekende, vertrouwde clients. Bied een duidelijke foutmelding met instructies wanneer een limiet wordt bereikt. Monitor actief op false positives en pas limieten aan.

Welk rate-limiting algoritme is het beste?

Het hangt af van je use case. Token bucket is geschikt wanneer je gecontroleerde bursts wilt toestaan. Leaky bucket is ideaal voor constante verwerkingssnelheid. Sliding window biedt de meeste nauwkeurigheid. Voor de meeste webapplicaties is token bucket een geschikte balans tussen flexibiliteit en bescherming.

Is rate-limiting verplicht voor API-security?

Hoewel niet wettelijk verplicht, beschouwen securitystandaarden als OWASP het ontbreken van rate-limiting als een kwetsbaarheid. Het staat in de OWASP API Security Top 10 onder API4: Unrestricted Resource Consumption. Voor organisaties die aan NIS2 moeten voldoen, is rate-limiting een verwachte maatregel.

Implementeer rate-limiting met de juiste partner. Bekijk Software Security aanbieders op IBgidsNL.