Wat is IP-rate-limiting?

IP-rate-limiting is een mechanisme dat het aantal verzoeken beperkt dat een IP-adres binnen een bepaalde periode naar een server kan sturen. Als je het limiet overschrijdt, weigert de server tijdelijk je verzoeken, doorgaans met een HTTP 429-fout ("Too Many Requests"). Het is een van de meest gebruikte tools om servers te beschermen tegen misbruik, denial-of-service-aanvallen en geautomatiseerde scraping.

Je bent het waarschijnlijk al tegengekomen zonder het te beseffen. Wanneer een site "Te veel pogingen, probeer het over 5 minuten opnieuw" toont na meerdere mislukte inlogpogingen, is dat rate limiting. Wanneer een API een fout retourneert na een bepaald aantal aanroepen per minuut, is dat rate limiting. Wanneer een zoekmachine je zoekopdrachten tijdelijk blokkeert omdat je te snel hebt gezocht, is dat ook rate limiting.

Waarom het nodig is

Een webserver heeft beperkte bronnen: CPU, geheugen, bandbreedte, databaseverbindingen. Elk verzoek verbruikt een deel van deze bronnen. Zonder enige beperking zou een enkele gebruiker (of een geautomatiseerd script) de server kunnen monopoliseren door duizenden verzoeken per seconde te sturen, waardoor de dienst ontoegankelijk wordt voor alle anderen.

Rate limiting beschermt tegen verschillende soorten bedreigingen:

DDoS- en brute-force-aanvallen. Een distributed denial-of-service-aanval (DDoS) overspoelt een server met verzoeken om deze onbeschikbaar te maken. Rate limiting alleen is niet voldoende om een massale DDoS-aanval te blokkeren (die van duizenden verschillende IP-adressen komt), maar het beperkt de schade die een enkel IP kan veroorzaken. Voor brute-force-aanvallen (duizenden wachtwoorden proberen) is rate limiting de eerste verdedigingslinie: het beperken tot 5 of 10 inlogpogingen per minuut maakt de aanval onpraktisch.

Misbruik van scraping en crawling. Bots die website-inhoud extraheren (prijzen, artikelen, data) sturen honderden verzoeken per seconde. Rate limiting vertraagt deze bots tot het punt waarop massale extractie economisch niet meer haalbaar is (te langzaam, te veel servertijd nodig).

API-misbruik. Publieke API's (weer, geolocatie, AI, betalingen) hebben kosten per verzoek voor de aanbieder. Zonder rate limiting zou een gebruiker onevenredig veel bronnen kunnen verbruiken, hetzij per ongeluk (een lus in de code) of opzettelijk. De meeste API's leggen limieten op per API-sleutel en per IP-adres.

Eerlijkheid tussen gebruikers. Zelfs zonder kwaadaardige opzet kan een "gulzige" gebruiker (die een pagina 50 keer per minuut vernieuwt, of een slecht geschreven script) de ervaring voor anderen verslechteren. Rate limiting zorgt voor een eerlijke verdeling van bronnen.

Hoe het technisch werkt

Het principe is eenvoudig: de server koppelt elk verzoek aan een IP-adres, telt het aantal verzoeken ontvangen van dat IP in een tijdvenster, en weigert verzoeken die de gedefinieerde drempel overschrijden. Maar de concrete implementatie varieert afhankelijk van het gebruikte algoritme.

Vast venster (Fixed Window). De tijd wordt verdeeld in vaste intervallen (bijvoorbeeld vensters van één minuut). De server telt verzoeken per IP in elk venster. Als je 100 verzoeken bereikt in het huidige venster, worden volgende geweigerd tot het begin van het volgende venster. Het is het eenvoudigste algoritme, maar het heeft een fout: als je 100 verzoeken stuurt aan het einde van een venster en 100 aan het begin van het volgende, heb je 200 verzoeken in enkele seconden gestuurd, het dubbele van het beoogde limiet.

Schuivend venster (Sliding Window). In plaats van vaste vensters kijkt de server op elk moment naar de laatste N seconden. Elk verzoek wordt geteld over een schuivende periode. Dit vlakt de verdeling af en elimineert het probleem van het vaste venster, maar vereist meer geheugen en berekening aan de serverzijde.

Token Bucket (emmer met tokens). Elk IP heeft een "emmer" met een vast aantal tokens. Elk verzoek verbruikt een token. Tokens worden met een constant tempo geregenereerd (bijvoorbeeld 10 per seconde). Als de emmer leeg is, wordt het verzoek geweigerd. Dit model staat korte pieken (bursts) toe: je kunt veel verzoeken tegelijk sturen als je emmer vol is, daarna moet je wachten op regeneratie. Het is het meest gebruikte algoritme in productie omdat het zowel flexibel als voorspelbaar is.

Leaky Bucket (lekkende emmer). Verzoeken komen in een wachtrij (de emmer) en worden met een constant tempo verwerkt (de leksnelheid). Als de emmer vol is, worden nieuwe verzoeken afgewezen. In tegenstelling tot Token Bucket dwingt Leaky Bucket een strikt constant uitgaande snelheid af, zonder pieken. Nuttig wanneer je een perfect gelijkmatige verwerkingsstroom wilt.

Waar rate limiting wordt toegepast

Rate limiting kan op verschillende niveaus van de netwerkinfrastructuur worden toegepast, en in de praktijk is dat vaak het geval: meerdere lagen worden op elkaar gestapeld.

Op webserverniveau. Nginx, Apache en de meeste webservers bevatten rate-limiting-modules. Nginx gebruikt bijvoorbeeld het Leaky Bucket-algoritme met zijn limit_req-directive. Je definieert een aantal verzoeken per seconde per IP, en Nginx regelt de rest. Effectief voor basisbescherming, maar de server moet elk verzoek nog steeds ontvangen en gedeeltelijk verwerken voordat het wordt afgewezen.

Op reverse-proxy- of load-balancerniveau. Rate limiting vóór de applicatieservers plaatsen (op een reverse proxy zoals Nginx of HAProxy, of een load balancer) maakt het mogelijk verzoeken te blokkeren voordat ze de applicatie bereiken. Dit is efficiënter qua bronnen.

Op CDN- of WAF-niveau. Diensten zoals Cloudflare, AWS WAF of Akamai passen rate limiting toe aan de netwerkrand (edge), voordat het verzoek zelfs je infrastructuur bereikt. Dit is de meest effectieve laag tegen volumetrische aanvallen, omdat het verzoek zo dicht mogelijk bij de bron wordt geblokkeerd.

Op applicatieniveau. De applicatie zelf kan rate limiting implementeren, vaak met meer granulariteit: per ingelogde gebruiker, per endpoint, per operatietype. Een API kan bijvoorbeeld 1.000 GET-verzoeken per minuut toestaan maar slechts 10 POST-verzoeken op een accountaanmaak-endpoint, omdat misbruik bij accountaanmaak een veelvoorkomende aanvalsvector is.

HTTP-headers gerelateerd aan rate limiting

Wanneer een server rate limiting toepast, communiceert het doorgaans de limietinformatie via HTTP-headers in het antwoord. Er is geen universele standaard, maar de meest gebruikte conventies zijn:

X-RateLimit-Limit: het maximale aantal toegestane verzoeken in het huidige tijdvenster. X-RateLimit-Remaining: het aantal resterende verzoeken voordat het limiet wordt bereikt. X-RateLimit-Reset: het moment (als Unix-tijdstempel of resterende seconden) waarop het venster reset en de teller opnieuw begint. Retry-After: een standaard HTTP-header die aangeeft hoe lang te wachten voordat je opnieuw probeert, geretourneerd met het 429-antwoord.

Een IETF-concept (RFC 6585 voor de 429-statuscode en recentere voorstellen) probeert deze headers te standaardiseren, maar in de praktijk gebruikt elke API zijn eigen conventie. Als je een applicatie bouwt die API's consumeert, lees altijd de API-documentatie om te begrijpen hoe het zijn limieten communiceert.

Waarom IP alleen niet altijd genoeg is

IP-gebaseerde rate limiting heeft een fundamenteel probleem: een IP-adres komt niet altijd overeen met één gebruiker.

CGNAT. Veel mobiele providers en sommige ISP's gebruiken CGNAT (Carrier-Grade NAT), waardoor honderden of duizenden gebruikers één publiek IPv4-adres delen. Als je een IP beperkt tot 100 verzoeken per minuut, beperk je in werkelijkheid alle gebruikers achter dat CGNAT tot een gecombineerd totaal van 100 verzoeken. Eén normale gebruiker kan het quotum voor alle anderen uitputten.

Bedrijfs- en universiteitsnetwerken. Duizenden werknemers of studenten kunnen via één publiek IP-adres (of een klein aantal adressen) toegang tot internet hebben. IP-gebaseerde rate limiting bestraft hen collectief.

VPN's en proxy's. VPN-gebruikers delen vaak een IP-adres met honderden anderen. Strikte IP-gebaseerde rate limiting kan legitieme gebruikers blokkeren simpelweg omdat ze dezelfde VPN-server gebruiken als een bot.

Dynamische IP-adressen. Omgekeerd kan een aanvaller gemakkelijk van IP-adres wisselen (met een proxypool, een botnet, of simpelweg door de vliegtuigmodus op de telefoon te schakelen) en IP-gebaseerde rate limiting omzeilen. Als het limiet per IP is en de aanvaller toegang heeft tot 10.000 adressen, wordt het effectieve limiet met 10.000 vermenigvuldigd.

Daarom combineren moderne rate-limiting-systemen IP doorgaans met andere identificatoren: API-sleutel, authenticatietoken, browservingerafdruk, sessiecookie. IP blijft een nuttig criterium, maar is zelden op zichzelf voldoende.

Wat er gebeurt als je gelimiteerd wordt

Het meest voorkomende antwoord is een HTTP 429-statuscode (Too Many Requests). De server kan ook een 503 (Service Unavailable) retourneren als de beperking het gevolg is van algemene overbelasting in plaats van een individuele overschrijding.

Sommige diensten blokkeren de toegang niet volledig maar degraderen de dienst: ze vertragen antwoorden (throttling), verminderen de kwaliteit van resultaten, of voegen een CAPTCHA toe om te verifiëren dat je een mens bent.

Andere diensten blokkeren stilzwijgend zonder een expliciet foutbericht. Ze blijven antwoorden met statuscode 200 (OK) maar retourneren lege gegevens of gedegradeerde resultaten. Deze "stille rate limiting" (shadow banning) is gebruikelijk op sociale netwerken en sommige zoekmachines, en is ontworpen om moeilijk detecteerbaar te zijn voor bots.

Hoe ontwikkelaars rate limiting afhandelen

Als je een applicatie bouwt die een API consumeert, moet je rate limiting correct afhandelen. De standaardmethode is "exponential backoff": wanneer je een 429-antwoord ontvangt, wacht je een bepaalde tijd voordat je opnieuw probeert, en verdubbel je die tijd bij elke opeenvolgende mislukking. Bijvoorbeeld: eerste poging na 1 seconde, tweede na 2 seconden, derde na 4 seconden, enzovoort.

Best practices omvatten:

De Retry-After- en X-RateLimit-Reset-headers lezen om precies te weten wanneer je opnieuw kunt proberen, in plaats van te gokken. Een cache implementeren om dezelfde verzoeken niet te herhalen. Verzoeken bundelen (batching) wanneer de API dit toestaat. Verzoeken over de tijd spreiden in plaats van ze in pieken te sturen. Een circuit breaker voorzien die API-aanroepen een tijdlang stopt als 429-fouten zich opstapelen, om de situatie niet te verergeren.

Rate limiting en privacy

IP-gebaseerde rate limiting betekent dat de server verzoeken per IP-adres identificeert en volgt. Dit is een vorm van verwerking van persoonsgegevens (het IP-adres wordt in veel rechtsgebieden als persoonsgegeven beschouwd, met name onder de AVG in Europa). Bedrijven die rate limiting implementeren zouden deze verwerking in theorie in hun privacybeleid moeten vermelden.

Vanuit het perspectief van de gebruiker betekent IP-gebaseerde rate limiting ook dat je activiteit wordt geteld. Als je om privacyredenen een VPN of proxy gebruikt, kan rate limiting je paradoxaal genoeg benadelen: je deelt een IP met andere gebruikers en het gedeelde quotum raakt sneller op.

Rate limiting omzeilen

Het wijzigen van je IP-adres (via een VPN, een roterende proxy, of de vliegtuigmodus op mobiel) maakt het mogelijk om rate limiting te omzeilen die uitsluitend op IP is gebaseerd. Commerciële scrapingdiensten gebruiken pools van duizenden residentiële IP-adressen om verzoeken te spreiden en onder de drempels per IP te blijven.

Maar moderne beschermingssystemen beperken zich niet tot IP. Ze combineren browservingerafdrukanalyse, surfgedrag (klikritme, muisbewegingen, tijd op pagina's), CAPTCHA's en analyse van verzoekpatronen om mensen van bots te onderscheiden, zelfs wanneer het IP bij elk verzoek verandert.

De wedloop tussen rate-limiting-systemen en omzeilingstechnieken is permanent. Methoden die vandaag werken, kunnen morgen worden gedetecteerd. Als je aan de serverzijde staat, is de beste strategie meerdere beschermingslagen te combineren in plaats van alleen op IP te vertrouwen.

Voorbeelden van veelvoorkomende limieten

Deze limieten variëren enorm afhankelijk van de dienst, het prijsplan en de context. Een betaalde API biedt doorgaans veel hogere limieten dan een gratis plan. Een gevoelig endpoint (inloggen, betaling, accountaanmaak) heeft veel lagere limieten dan een data-lees-endpoint.

IP-rate-limiting is een essentiële bescherming voor elke server die aan internet is blootgesteld. Het voorkomt misbruik, beschermt bronnen en zorgt voor eerlijke toegang. Maar IP alleen is met CGNAT, VPN's en proxy's een steeds minder betrouwbare identificator. Moderne systemen combineren IP met andere signalen om legitiem verkeer van misbruik te onderscheiden, en het is die combinatie die het verschil maakt tussen effectieve bescherming en een eenvoudig filter dat gemakkelijk te omzeilen is.