Definitie
Rate limiting is een verkeersbeheercontrole die een bovengrens afdwingt op hoe vaak een client een bepaalde actie binnen een gespecificeerd tijdvenster kan uitvoeren. Wanneer een client de drempel overschrijdt, antwoordt de server met een fout — typisch HTTP 429 Too Many Requests — of laat de overtollige verzoeken stilzwijgend vallen. Het tijdvenster wordt opnieuw gestart op een vast schema (een “vast venster” teller) of op rollende basis (een “schuivend venster” teller), waarbij schuivende vensters gladdere handhaving bieden die uitbarstings-uitbuiting bij venstergrenzen voorkomt.
Rate limiting is een van de oudste en meest universeel ingezette web-beveiligingscontroles. OWASP (Open Web Application Security Project) beveelt het aan als primaire verdediging tegen brute-force-aanvallen, credential stuffing en geautomatiseerd formuliermisbruik. Cloudflare biedt rate limiting als functie van zijn WAF-product, met regels configureerbaar op URL-pad, HTTP-methode, IP-adres, cookie-waarde en request-header. AWS WAF, Azure Front Door en Google Cloud Armor bieden equivalente mogelijkheden.
Hoe rate limiting werkt
Een rate limiter onderhoudt een teller voor elke unieke client-identifier — meestal het bron-IP-adres, maar soms een account-identifier, een API-sleutel of een sessie-cookie. Wanneer een verzoek aankomt, controleert de server de huidige tellerwaarde voor die identifier. Als de teller onder de drempel ligt, wordt het verzoek toegestaan en wordt de teller verhoogd. Als de teller op of boven de drempel ligt, wordt het verzoek afgewezen met een 429-antwoord of behandeld volgens het geconfigureerde beleid.
Tellersopslag wordt typisch geïmplementeerd in Redis of Memcached om snelle, gedistribueerde lookups over meerdere serverinstanties mogelijk te maken — een vereiste voor horizontaal geschaalde applicaties. De Cloudflare-documentatie beschrijft rate limiting-handhaving op edge-netwerkniveau, waar regels worden toegepast voordat verzoeken de origin-server bereiken, waardoor de loadreductie wordt verdeeld over de globale infrastructuur van Cloudflare.
Veelvoorkomende rate limiting-parameters in een wedstrijdcontext zijn:
- Stemmen per IP per tijdvenster: De meest voorkomende configuratie. Voorbeeld: niet meer dan 1 stem per IP-adres per 24-uursvenster.
- Stemmen per account per wedstrijd: Gehandhaafd op applicatielaag met de account-identifier van de geauthenticeerde gebruiker als sleutel.
- Registraties per IP per uur: Toegepast op het account-aanmaakeindpunt om bot-aangedreven account-farming te vertragen.
- API-aanroepen per token per minuut: Relevant voor wedstrijdplatformen die een openbare stem-API blootstellen.
Rate limiting kan ook probabilistisch worden toegepast — bijvoorbeeld striktere limieten toepassen op verzoeken die binnenkomen met gedrags- of fingerprint-signalen die op automatisering wijzen, terwijl lossere limieten worden toegepast op sessies met hoge-betrouwbare menselijke indicatoren.
Waar je het tegenkomt
Rate limiting is een alomtegenwoordige controle die in vrijwel elk webplatform aanwezig is. Wedstrijdorganisatoren komen het meest direct op drie punten tegen: het stem-inzendingseindpunt, het account-registratieformulier, en (als e-mailbevestiging vereist is) de e-mailverzendpipeline. API-aangedreven wedstrijdintegraties komen rate limits tegen op de API-eindpunten van het platform.
Voor eindgebruikers manifesteert rate limiting zich het zichtbaarst als een HTTP 429-fout of een platformspecifiek bericht zoals “Je hebt al gestemd” of “Wacht alsjeblieft voordat je opnieuw stemt.” Veel platformen implementeren zachte rate limiting — het verzoek accepteren maar het duplicaat stilzwijgend weggooien — om te voorkomen dat het bestaan van de controle aan potentiële misbruikers wordt gesignaleerd.
Cloudflare’s WAF rate limiting-documentatie merkt op dat rate limiting-regels kunnen worden ingesteld om te loggen zonder te blokkeren tijdens een analysefase, en daarna naar blokkeren worden geschakeld zodra de juiste drempel is gekalibreerd. Deze tweefasige aanpak helpt wedstrijdorganisatoren om legitieme stempieken niet per ongeluk te blokkeren.
Praktische voorbeelden
Een eten-blogger awardcompetitie configureert zijn stemsysteem met een 24-uurs per-IP rate limit. Tijdens de laatste week van de wedstrijd probeert een kiezer 50 stemmen in snelle opeenvolging in te dienen vanaf hetzelfde residentiële IP-adres. De eerste stem wordt geaccepteerd; de daaropvolgende 49 verzoeken ontvangen een 429-antwoord. De browser van de kiezer toont een bericht waarin de eens-per-dag-beperking wordt uitgelegd.
Een SaaS wedstrijdplatform dat honderden gelijktijdige wedstrijden host, gebruikt Cloudflare’s rate limiting op de netwerkrand. Een bot die één wedstrijd target met 10.000 verzoeken per minuut wordt gethrottled tot maximaal 60 verzoeken per minuut op de rand, waarbij de overtollige verzoeken nooit de origin-server bereiken. De logs van de origin-server tonen alleen het gethrottelde verkeer, en het CPU-gebruik op serverzijde blijft onaangetast.
Een OWASP-beveiligingsreview van de aangepaste wedstrijd-microsite van een startup identificeert de afwezigheid van rate limiting op het e-mailbevestiging-resend-eindpunt als een kwetsbaarheid — een aanvaller zou de inbox van een slachtoffer kunnen overspoelen door duizenden bevestigingsmails te triggeren. De review beveelt aan om een rate limit van 3 resend-verzoeken per e-mailadres per uur te implementeren, in lijn met OWASP’s brute-force-preventierichtlijnen.
Verwante begrippen
Anomaliedetectie is een geavanceerdere aanvulling op rate limiting: waar rate limiting harde drempels handhaaft, identificeert anomaliedetectie afwijkingen van een geleerde gedragsbaseline en vangt fraudecampagnes op die net onder vaste limieten blijven. ASN-diversiteit wordt relevant wanneer rate limits per-IP worden toegepast en een kwaadwillende verzoeken verspreidt over veel IP-adressen om onder per-IP-drempels te blijven — ASN-niveau-analyse detecteert het aggregaat-patroon. reCAPTCHA v3 biedt een gedragsrisicoscore die gecombineerd kan worden met rate limiting om strakkere limieten selectief toe te passen op sessies die als potentieel geautomatiseerd scoren.
Beperkingen / kanttekeningen
IP-gebaseerde rate limiting is minder effectief in omgevingen met carrier-grade NAT, waar één publiek IP honderden legitieme mobiele abonnees kan vertegenwoordigen. Een per-IP rate limit van 1 stem per 24 uur zou ten onrechte de meeste van die abonnees verhinderen om te stemmen. Daarom moet rate limiting op wedstrijdplatformen worden gelaagd met account-gebaseerde of cookie-gebaseerde ontdubbeling wanneer mobiele publieksgroepen significant zijn. Bovendien kunnen te agressief ingestelde rate limits de ervaring degraderen voor legitieme kiezers die binnenkomen via gedeelde netwerken zoals universiteitscampussen, bedrijfskantoren of grote openbare Wi-Fi-hotspots.
