Rate Limiting

Snelheidsbeperking, API-throttling, Throttling, Verzoeklimiet, Request limiting, Aanvraaglimiet
Rate limiting beperkt het aantal verzoeken dat een gebruiker of systeem binnen een bepaalde tijd naar je server mag sturen. Het beschermt je infrastructuur tegen overbelasting en misbruik.

Wat is Rate Limiting?

Rate limiting is een techniek die het aantal verzoeken (requests) beperkt dat een gebruiker, IP-adres of API-client binnen een bepaalde periode naar je server mag sturen. Stel je voor dat je webshop 100 aanvragen per minuut toestaat per gebruiker. Stuurt iemand verzoek nummer 101? Dan krijgt die een foutmelding of een wachttijd. Voor MKB-bedrijven met een website, webshop of API-koppeling is dit de digitale poortwachter die voorkomt dat je server vastloopt door overbelasting, bots of kwaadwillenden.

Hoe rate limiting werkt in de praktijk

Een rate limiter houdt bij hoeveel verzoeken een specifieke bron (bijvoorbeeld een IP-adres, API-key of ingelogde gebruiker) binnen een tijdsvenster doet. Dit tijdsvenster kan een seconde, minuut of uur zijn. Veelgebruikte strategieën zijn het token bucket-algoritme, waarbij elke gebruiker een 'emmer' met tokens krijgt die langzaam bijgevuld wordt, en het sliding window-principe, dat een glijdend gemiddelde bijhoudt. Zodra de limiet bereikt is, blokkeert het systeem nieuwe verzoeken tijdelijk of vertraagt het de respons. In een professionele webontwikkelomgeving configureer je dit vaak via de webserver (zoals Nginx of Apache), een CDN of binnen de applicatiecode zelf.

Waarom rate limiting essentieel werd voor moderne websites

Rate limiting ontstond in de vroege jaren van API-economie, toen diensten zoals Twitter en Google merkten dat ongecontroleerd gebruik hun infrastructuur kon lamleggen. Een enkele bot die duizenden verzoeken per seconde afvuurt, kan een server net zo effectief platleggen als een DDoS-aanval. Voor Nederlandse webshops en SaaS-platforms is dit nog steeds actueel: credential stuffing-aanvallen, scraping door concurrenten en onbedoelde loops in externe koppelingen komen dagelijks voor. Rate limiting is daarom geen luxe maar een basisbescherming, vergelijkbaar met authentication en authorization.

Wat rate limiting oplevert voor jouw bedrijf

Voor een MKB-webshop met 5.000 bezoekers per dag voorkomt rate limiting dat een enkele bot je checkout-pagina 10.000 keer per minuut oproept en daarmee je hosting overbelast. Voor een B2B-platform met API-koppelingen naar klanten beschermt het je tegen onbedoelde loops in externe software die je server onnodig belasten. Daarnaast helpt het bij eerlijke verdeling: geen enkele gebruiker kan alle beschikbare capaciteit claimen. In de praktijk zien we bij WordPress-hostingtrajecten vaak dat rate limiting op serverniveau de uptime verbetert en de kosten verlaagt, omdat je minder overhead nodig hebt voor piekbelasting. Volgens Google Developers helpt rate limiting ook bij het beheersen van crawl budget, zodat zoekmachines efficiënter je site indexeren.

Toepassingen van Rate Limiting

Rate limiting is geen abstracte techniek voor grote techbedrijven. Ook Nederlandse MKB-bedrijven met een website, webshop of API profiteren dagelijks van slimme beperkingen. Hieronder vier concrete situaties waarin rate limiting het verschil maakt tussen een stabiele dienstverlening en een overbelaste server.

Bescherming van inlogpagina's tegen brute force-aanvallen

Een veelvoorkomende aanval is credential stuffing: criminelen proberen duizenden combinaties van gebruikersnaam en wachtwoord uit op je inlogpagina. Zonder rate limiting kan een bot in enkele minuten miljoenen pogingen doen. Met rate limiting beperk je bijvoorbeeld tot 5 inlogpogingen per IP-adres per minuut. Na de vijfde poging krijgt de gebruiker een tijdelijke blokkade van 15 minuten. Voor legitieme gebruikers is dit nauwelijks merkbaar, maar voor aanvallers wordt het economisch onhaalbaar. In de praktijk merken we bij klanten dat deze simpele maatregel 99% van de brute force-pogingen stopt, zonder dat echte bezoekers er last van hebben. Combineer dit met two-factor authentication voor een extra beschermingslaag.

Eerlijke verdeling van API-capaciteit voor externe koppelingen

Stel je hebt een webshop met een API waarmee externe systemen (zoals een ERP of marketingautomatiseringstool) productdata ophalen. Zonder rate limiting kan één klant met een foutieve configuratie je API overspoelen met verzoeken en daarmee andere klanten vertragen. Door een limiet van bijvoorbeeld 1.000 verzoeken per uur per API-key in te stellen, garandeer je eerlijke verdeling. Dit is vooral relevant voor B2B-platforms en SaaS-diensten. Je communiceert de limiet vooraf in je API-documentatie, zodat ontwikkelaars hun integraties daarop kunnen afstemmen. Bij Monkey Vision configureren we dit vaak via API-koppelingen met tools als n8n, waarbij we rate limiting aan beide kanten instellen: zowel bij de bron als bij de bestemming.

Voorkomen van scraping door concurrenten of bots

Webshops en vergelijkingssites worden regelmatig gescraped door concurrenten die prijzen en productinformatie automatisch verzamelen. Een scraper kan in korte tijd honderden pagina's opvragen, wat je server belast en je concurrentievoordeel ondermijnt. Rate limiting op basis van IP-adres of user-agent beperkt dit: bijvoorbeeld maximaal 60 pagina's per minuut per IP. Legitieme bezoekers halen dit nooit, maar een scraper wordt direct vertraagd. Let op: te strenge limieten kunnen ook Google-bots hinderen. Volgens Google's crawler-documentatie is een limiet van 1 verzoek per seconde voor de meeste sites veilig. Combineer rate limiting met een robots.txt en monitoring om het evenwicht te vinden.

Stabiliteit van checkout en betaalpagina's tijdens pieken

Black Friday, een productlancering of een virale social media-post kan plotseling duizenden bezoekers naar je webshop sturen. Zonder rate limiting kan je checkout-proces vastlopen doordat te veel sessies tegelijk worden aangemaakt. Door rate limiting op kritieke endpoints (zoals het aanmaken van een winkelwagentje of het starten van een betaling) te zetten, voorkom je dat je infrastructuur overbelast raakt. Je kunt bijvoorbeeld 10 checkout-starts per minuut per sessie toestaan, wat voor normale gebruikers ruim voldoende is maar voorkomt dat bots of bugs je systeem lamleggen. In combinatie met professionele webshop-ontwikkeling en schaalbare hosting houd je ook tijdens pieken de controle.

Wanneer rate limiting de juiste keuze is en wanneer niet

Rate limiting is zinvol zodra je website, API of webshop te maken krijgt met geautomatiseerd verkeer, externe koppelingen of een groeiend aantal gebruikers. Het is geen overkill voor kleine sites: zelfs een eenvoudige WordPress-site profiteert van basisbeveiliging tegen inlogpogingen. Wél moet je oppassen met te strikte limieten op publieke pagina's: als je homepage maar 10 verzoeken per minuut per IP toestaat, kunnen gebruikers achter een gedeeld bedrijfsnetwerk of VPN elkaar blokkeren. Test daarom altijd met realistische scenario's en monitor je logs. Voor sites met weinig dynamische interactie (bijvoorbeeld een eenvoudige portfolio-site zonder inlog) kun je rate limiting beperken tot specifieke endpoints zoals contactformulieren.

Wil je dit toepassen in jouw bedrijf? Monkey Vision helpt MKB-ondernemers met webdesign, SEO en slimme digitale oplossingen. Plan een vrijblijvende kennismaking en ontdek wat er voor jou mogelijk is.

Plan een kennismaking

Veelgestelde vragen

Nee, rate limiting en een firewall zijn complementaire beveiligingslagen met verschillende doelen. Een firewall blokkeert verkeer op basis van herkomst, protocol of bekende bedreigingen, terwijl rate limiting de frequentie van verzoeken beperkt, ongeacht de bron. Je kunt een vertrouwd IP-adres hebben dat door de firewall komt, maar als dat adres te veel verzoeken doet, grijpt rate limiting in. In de praktijk combineer je beide: de firewall houdt kwaadwillend verkeer tegen, en rate limiting voorkomt dat legitieme maar overactieve gebruikers of bugs je server overbelasten. Voor optimale beveiliging van je website of API heb je dus beide nodig, aangevuld met authentication en monitoring.

Dat hangt af van je verkeerspatroon en risicoprofiel. Voor een webshop met voornamelijk Nederlandse bezoekers volstaat vaak een limiet van 100 tot 200 verzoeken per minuut per IP-adres voor productpagina's, en 5 tot 10 voor inlog- en checkoutpagina's. Heb je een API voor externe koppelingen? Gebruik dan per-key limieten van 1.000 tot 5.000 verzoeken per uur, afhankelijk van je infrastructuur. Start conservatief en monitor je access logs: zie je legitieme gebruikers die de limiet raken? Verhoog dan geleidelijk. Zie je veel geblokkeerde bots? Verlaag de limiet voor specifieke endpoints. Bij twijfel helpt een professionele hosting-setup met ingebouwde rate limiting en real-time monitoring om de juiste balans te vinden zonder trial-and-error op je live omgeving.

De meest voorkomende fout is te strikte limieten op publieke pagina's, waardoor gebruikers achter een gedeeld IP-adres (zoals een kantoornetwerk of mobiele provider) elkaar blokkeren. Een tweede valkuil is rate limiting toepassen zonder duidelijke foutmeldingen: bezoekers krijgen een generieke 429-error zonder uitleg of alternatief. Geef altijd aan wanneer de limiet weer reset. Een derde fout is rate limiting instellen maar nooit monitoren: je weet dan niet of legitieme gebruikers last hebben of dat bots nog steeds doorbreken. Los dit op door logging en alerting in te richten, bijvoorbeeld via je hostingprovider of een tool als Google Analytics. Ten slotte: vergeet niet om je eigen systemen (zoals monitoring-tools of backupdiensten) uit te zonderen, anders blokkeer je jezelf. Test altijd met realistische scenario's voordat je live gaat.

De beste aanpak hangt af van je huidige infrastructuur en risico's. Draai je een WordPress-site of webshop en wil je snel basisbeveiliging? Begin dan met rate limiting op inlogpagina's en formulieren via een plugin of je hostingprovider. Heb je een custom applicatie of API? Configureer rate limiting op serverniveau (Nginx, Apache) of binnen je applicatiecode. Weet je niet waar je moet beginnen of welke limieten realistisch zijn? Plan dan een gratis beveiligingsscan van 30 minuten met Monkey Vision. We lopen je huidige setup door, identificeren kwetsbare endpoints en geven direct drie concrete verbeterpunten die je deze week kunt implementeren. Geen verkooppraatje, wel praktisch advies afgestemd op jouw situatie. Neem contact op via onze webontwikkelingspagina om een afspraak in te plannen.

Over de auteur

Monkey Vision

Monkey Vision is een full-service digitaal bureau in Nijmegen, gespecialiseerd in webdesign, SEO en AI-automatisering voor het MKB. De kennisbank is samengesteld door ons team van online-strategen en doorlopend bijgehouden op basis van actuele inzichten.

Publicatiedatum: 26-04-2026
Laatste update: 26-04-2026