Webshop beveiligen tegen bots: carding, credential stuffing en scraping

Je ziet 4.000 mislukte logins in een nacht. Of 600 bestellingen van een paar euro met kaarten die allemaal worden geweigerd. Of je zoekfunctie krijgt tien keer zoveel verkeer als normaal, en je server zweet. Dat zijn geen hackers die inbreken. Het zijn bots die je shop gebruiken zoals hij bedoeld is, maar dan duizend keer sneller.

Dit artikel laat zien hoe je de drie meest voorkomende botaanvallen herkent in je logs, en welke laag erbij hoort: WAF, rate limiting, een captcha-alternatief of de regels van je betaalprovider. Het overzicht van al onze security-content staat op de security-pagina.

Waarom bots geen "hack" zijn

Een bot vraagt gewone pagina's op en post gewone formulieren. Niets daarvan is een kwetsbaarheid. Daarom ziet je patchniveau er prima uit terwijl je toch last hebt. Je lost het niet op met een update, maar met regels over wie hoe vaak iets mag doen.

Er zijn drie aanvallen die je in een webshop steeds terugziet.

1. Carding: gestolen kaarten testen op jouw checkout

Bij carding proberen aanvallers of gestolen kaartnummers nog werken. Jouw shop is het testlokaal: een kleine bestelling, een kaart die wel of niet wordt geaccepteerd. Het schadelijke zit niet in het bedrag. Het zit in de gevolgen: betaalproviders zien een stortvloed aan geweigerde transacties, je kosten lopen op en in het ergste geval grijpt je provider in.

Zo herken je het:

• Veel betaalpogingen met kleine bedragen.
• Een hoog percentage geweigerde of mislukte betalingen.
• Veel verschillende kaarten vanaf weinig IP-adressen, of juist veel IP-adressen met dezelfde patronen.
• Bestellingen met onzinnige namen en e-mailadressen.
• Pieken buiten kantoortijd.

2. Credential stuffing: gelekte wachtwoorden uitproberen

Aanvallers hebben lijsten met e-mailadressen en wachtwoorden uit andere datalekken. Ze proberen die op je klantlogin. Mensen hergebruiken wachtwoorden, dus een deel werkt altijd. Met een gekaapt account kunnen ze bestellen op andermans naam, adressen bekijken of kortingstegoed leegtrekken.

Zo herken je het:

• Veel POST-verzoeken naar het loginpad, met een hoog foutpercentage.
• Weinig herhaling per account: elk e-mailadres maar één of twee keer.
• Verkeer vanaf een groot aantal IP-adressen, vaak residentiële, zodat een IP-blokkade weinig doet.
• Plotselinge pieken in wachtwoord-reset-verzoeken.

3. Scraping: je catalogus en prijzen kopiëren

Concurrenten en prijsvergelijkers halen je producten, prijzen en voorraad binnen. Eén scraper is niet erg. Tientallen tegelijk, op je zoekfunctie en categoriepagina's, kosten je serverkracht en vertragen echte klanten.

Zo herken je het:

• Een client die systematisch door alle productpagina's of paginering loopt.
• Veel verzoeken op zoek- en filter-URL's.
• Opvallende user agents, of juist heel gewone user agents met een onmenselijk tempo.
• Verzoeken zonder cookies of zonder referer.

Eerst kijken, dan blokkeren

Open je serverlogs of je monitoring en beantwoord vier vragen:

1. Welke paden krijgen het meeste verkeer?
2. Hoeveel verzoeken per minuut komen er van één IP-adres?
3. Wat is het foutpercentage op login en checkout?
4. Wanneer begon het, en valt dat samen met een campagne of een externe gebeurtenis?

Zonder dit blokkeer je op gevoel. En bij gevoel blokkeer je te vroeg een echte klant of te laat een bot.

Welke laag past bij welke aanval

De WAF

Een Web Application Firewall filtert verkeer op patronen: bekende aanvalshandtekeningen, verdachte user agents, landen, paden. Het is nuttig tegen bekende aanvallen en tegen het grove bulkverkeer. Het is minder geschikt tegen bots die zich gedragen als gewone bezoekers. Ook een WAF vervangt patchen niet.

Rate limiting

Rate limiting beperkt hoe vaak één bron iets mag doen binnen een tijdsvenster. Het is de meest effectieve laag tegen carding en credential stuffing, omdat die aanvallen op volume leunen. Kies de limiet zo dat een mens hem nooit haalt en een bot hem snel overschrijdt. Let op gedeelde IP-adressen: een kantoor of mobiel netwerk kan veel echte klanten achter één adres hebben.

Een captcha-alternatief

Een onzichtbare of lichte controle op formulieren voegt een stap toe die bots lastig vinden en mensen nauwelijks merken. Zet hem op login, registratie, wachtwoord vergeten en de betaalstap. Controleer het token altijd op de server. Alleen een widget in de pagina houdt een bot niet tegen, want die post gewoon rechtstreeks naar je endpoint.

De regels van je betaalprovider

Veel betaalproviders hebben eigen risico- en fraudecontroles, zoals limieten per kaart of IP en extra verificatie. Vraag je provider welke opties jouw account heeft. Dit is de enige laag die rechtstreeks kijkt naar het kaartgedrag zelf. Zet je webhook-paden daarbij niet achter dezelfde controle als je klantverkeer, anders raak je statusupdates kwijt.

Een praktische volgorde

1. Meet. Stel een basislijn vast van normaal verkeer per pad.
2. Rate limiting op login en checkout. Begin ruim en trek aan op basis van wat je ziet.
3. Een captcha-alternatief op formulieren, met validatie op de server.
4. Overleg met je betaalprovider over risicoregels voor carding.
5. Bot-detectie op domeinniveau, pas na het opstellen van uitzonderingen voor je eigen koppelingen.
6. Controleer na elke wijziging of je klanten en je koppelingen nog doorkomen.

Wat je niet doet

• Hele landen blokkeren zonder naar je klanten te kijken. Je blokkeert ook echte klanten.
• Alleen IP's blokkeren. Aanvallers wisselen van adres. Je loopt dan achter de feiten aan.
• Challenges op API-verzoeken. Een challenge-pagina kan niet getoond worden aan een script. Voor API's blokkeer of limiteer je.
• Webhooks vergeten. Betaal-, ERP- en verzendkoppelingen zijn geautomatiseerd verkeer dat je wilt toelaten.
• Zonder meten uitrollen. Een regel die je niet kunt terugkijken in je logs kun je niet verbeteren.

Bots en je compliance

Hoge aantallen mislukte betalingen en gekaapte klantaccounts raken ook je verplichtingen: je betaalprovider kan maatregelen eisen, en bij een account-overname kan er sprake zijn van een datalek. Zie PCI DSS 4.0 voor webshops voor wat er rond je betaalpagina geldt, en je incident response plan voor het geval het misgaat. Dit is geen juridisch advies.

Voor de koppelingen tussen je systemen: API-beveiliging voor e-commerce. Vergelijk je diensten die dit verkeer voor je filteren, lees dan Cloudflare vs Fastly voor e-commerce.

Veelgestelde vragen

Hoe herken ik carding op mijn webshop?

Kijk naar veel kleine bestellingen met een hoog percentage geweigerde betalingen, veel verschillende kaarten vanaf weinig bronnen en onzinnige klantgegevens. Je betaalprovider ziet het patroon vaak eerder dan jij.

Helpt een WAF tegen credential stuffing?

Deels. Een WAF filtert bekend schadelijk verkeer, maar credential stuffing lijkt op gewone logins. Rate limiting, een captcha-alternatief en 2FA werken beter.

Moet ik scrapers altijd blokkeren?

Nee. Zoekmachines wil je juist toelaten. Blokkeer of limiteer het gedrag dat je server of je prijsstrategie schaadt, niet het crawlen zelf.

Kan ik bots blokkeren zonder echte klanten te raken?

Niet volledig. Je werkt met afwegingen: ruimere limieten en uitdagingen in plaats van harde blokkades, en je controleert na elke wijziging je conversie en je logs.

Wil je dat iemand je botverkeer analyseert en de juiste lagen inricht? Neem contact op.