Webshopbeveiliging wordt vaak gezien als een technisch onderwerp. Denk aan SQL-injecties, Cross-Site Scripting, kwetsbare plugins, slechte authenticatie of verouderde software.
Dat zijn terechte aandachtspunten.
Maar fraude in webshops ontstaat lang niet altijd door klassieke technische kwetsbaarheden. In de praktijk gaat het vaak mis in de logica van de webshop zelf: de regels die bepalen hoe bestellingen, kortingen, betalingen, retouren en accounts werken.
Een webshop kan technisch goed functioneren en toch kwetsbaar zijn voor misbruik.
Niet omdat iemand “inbreekt” op de traditionele manier, maar omdat iemand de bestaande functionaliteit slimmer gebruikt dan bedoeld.
Dat maakt businesslogica zo belangrijk bij webshopbeveiliging.
Wat bedoelen we met businesslogica?
Businesslogica is de verzameling regels die bepaalt hoe een webshop zich gedraagt.
Het gaat bijvoorbeeld om vragen als:
Wanneer wordt een bestelling definitief?
Mag een kortingscode worden toegepast?
Wanneer krijgt iemand geld terug?
Welke prijs geldt bij meerdere acties?
Wanneer wordt voorraad gereserveerd?
Wanneer mag een gebruiker een order wijzigen of annuleren?
Dit zijn geen technische details aan de kant van de webshop. Dit zijn de regels waarop het commerciële proces draait.
Juist daarom kunnen fouten in businesslogica direct leiden tot financieel verlies, fraude of operationele verstoring.
Het lastige is dat dit soort fouten er aan de buitenkant vaak niet uitzien als kwetsbaarheden. De webshop geeft geen foutmelding. De betaling verloopt via de juiste flow en de gebruiker is gewoon ingelogd. Alles lijkt legitiem.
Maar de uitkomst klopt niet.
Waarom businesslogica kwetsbaar kan zijn
Businesslogica wordt meestal ontworpen vanuit normaal gebruik.
Een klant plaatst een bestelling.
Een kortingscode wordt één keer toegepast.
De betaling wordt afgerond voordat een order wordt verwerkt.
Een retour wordt gekoppeld aan een daadwerkelijke bestelling.
Dat zijn logische aannames.
Alleen gebruiken aanvallers en fraudeurs een systeem niet altijd zoals het bedoeld is. Zij testen juist wat er gebeurt als stappen worden herhaald, gecombineerd, overgeslagen of in een andere volgorde worden uitgevoerd.
Wat gebeurt er als iemand twee kortingscodes toevoegt?
Hoe gaat het systeem om met een betaling die wordt afgebroken terwijl de orderstatus toch wijzigt?Welke gevolgen heeft het als de retourprocedure wordt gestart voordat de levering is afgerond?
Wat gebeurt er als een orderbedrag in de frontend wordt aangepast?
Dat zijn geen klassieke technische exploits. Het zijn vragen over gedrag.
Daarom blijven businesslogica-risico’s vaak buiten beeld bij standaard securitycontroles.
Een webshop kan werken maar toch misbruikt worden
Een belangrijk punt bij businesslogica is dat de webshop vaak gewoon blijft werken.
Dat maakt deze risico’s lastig.
Bij een technische fout is het probleem soms zichtbaar: een crash, foutmelding, mislukte betaling of geblokkeerde actie. Bij businesslogica gaat het subtieler. Het systeem verwerkt de actie gewoon, maar de uitkomst is ongewenst.
Bijvoorbeeld: een klant krijgt een hogere korting dan bedoeld. Of een refund wordt verwerkt terwijl daar geen geldige reden voor is. Een orderstatus verandert voordat de betaling definitief is bevestigd. Een gebruiker kan een bestelling aanpassen terwijl dat proces eigenlijk al afgesloten had moeten zijn.
De webshop doet dus iets wat technisch mogelijk is, maar zakelijk niet toegestaan zou moeten zijn.
Dat verschil is precies waar fraude ontstaat.
Voorbeeld: misbruik van kortingscodes
Kortingen zijn een klassiek voorbeeld van businesslogica die verkeerd kan uitpakken.
Een webshop heeft bijvoorbeeld meerdere acties: een welkomstkorting, een kortingscode, gratis verzending en een staffelkorting. Los van elkaar werkt dit prima.
Het probleem ontstaat wanneer ze gecombineerd kunnen worden op een manier die niet zo bedoeld is.
Een gebruiker voegt eerst een kortingscode toe, activeert daarna een actie via een andere route en wijzigt vervolgens de inhoud van de winkelwagen. Als de webshop niet opnieuw controleert of de combinatie nog geldig is, kan de uiteindelijke prijs lager uitvallen dan de bedoeling was.
Dit hoeft geen technische kwetsbaarheid te zijn in de klassieke zin.
De checkout werkt.
De kortingscode werkt.
De order wordt netjes verwerkt.
Maar de acties worden in een bepaalde volgorde uitgevoerd waar onvoldoende rekening mee is gehouden.
Voor de klant lijkt het misschien een slimme truc. Voor de webshop kan het structureel omzetverlies betekenen.
Voorbeeld: betaalstatus en orderverwerking
Betaalflows zijn een ander belangrijk risicogebied.
Een webshop moet precies weten wanneer een betaling definitief is. Niet wanneer een betaling gestart is. Niet wanneer iemand terugkeert vanaf een betaalprovider. En ook niet wanneer er lokaal een status verandert. Maar wanneer de betaling daadwerkelijk bevestigd is.
Als die controle niet strikt genoeg is, kunnen er ongewenste situaties ontstaan.
Een order wordt bijvoorbeeld aangemaakt voordat de betaling definitief is afgerond. Of een orderstatus wijzigt doordat een gebruiker terugkeert naar een bevestigingspagina, terwijl de betaalprovider nog geen definitieve bevestiging heeft gegeven.
In goed ingerichte webshops wordt dit meestal server-side gecontroleerd via betrouwbare betaalstatussen of webhooks. Maar bij maatwerk, plugins, externe koppelingen of complexe flows kunnen inconsistenties ontstaan.
Het risico draait niet om één specifieke kwetsbaarheid, maar om de timing en de interactie tussen verschillende systemen.
Juist dat maakt betaalflows interessant om te testen.
Voorbeeld: retourneren en terugbetalen
Retour- en terugbetalingsprocessen zijn gevoelig voor misbruik omdat ze meerdere systemen raken.
Retourneren heeft vaak invloed op de voorraad, orderstatus, betaling, klantcommunicatie en financiële administratie. Als die onderdelen niet consistent samenwerken, kunnen er zwakke problemen ontstaan.
Denk aan situaties waarin een gebruiker meerdere retouraanvragen kan starten voor dezelfde order. Of waarin een terugbetaling wordt verwerkt terwijl de retournering nog niet ontvangen is. Of waarin een gedeeltelijke retournering leidt tot een volledige terugbetaling.
Het proces werkt misschien precies zoals het ooit gebouwd is. Alleen is niet goed nagedacht over afwijkend gedrag of misbruik.
Bij webshopfraude maken aanvallers vaak misbruik van dit soort scenario’s.
Waarom vulnerability scanners dit niet ontdekken
Vulnerability scans zijn nuttig voor bekende kwetsbaarheden en zichtbare configuratieproblemen. Maar businesslogica laat zich lastig scannen.
Zo weet een vulnerability scanner niet welke kortingscombinaties toegestaan zijn. Een scanner begrijpt niet wanneer een orderstatus zakelijk gezien definitief hoort te zijn. Een scanner weet niet of een retournering logisch is binnen het bestelproces.
Daarvoor is context nodig.
Je moet begrijpen hoe de webshop werkt, welke stappen normaal zijn en waar iemand kan afwijken. Je moet processen volgen, acties herhalen, volgordes aanpassen en kijken of controles op het juiste moment plaatsvinden.
Dat is precies waarom businesslogica-risico’s vaak pas zichtbaar worden tijdens handmatig onderzoek.
Het verschil tussen een vulnerability scan en een pentest is hier belangrijk: een vulnerability scan kijkt vooral naar bekende signalen, terwijl een pentest onderzoekt wat iemand in de praktijk kan bewerkstelligen.
Waarom businesslogica vaak tussen wal en schip valt
Businesslogica-risico’s zijn lastig omdat ze niet altijd duidelijk van één team zijn.
Development kijkt of de functionaliteit werkt.
Security kijkt naar technische kwetsbaarheden.
Operations kijkt naar stabiliteit.
Finance kijkt naar betalingen.
Marketing kijkt naar acties en kortingscodes.
Maar fraude ontstaat vaak precies tussen die gebieden.
Een kortingscode kan functioneel gezien correct lijken, maar wordt niet opnieuw gevalideerd bij een wijziging in de winkelwagen. Een betaalstatus klopt technisch, maar wordt te vroeg gebruikt in het orderproces. Een retourflow werkt voor normale klanten, maar houdt geen rekening met meerdere retouraanvragen of timingverschillen. Wanneer dit soort processen via API’s lopen, kan een API pentest helpen om te onderzoeken of controles ook buiten de webshop voldoende werken.
Iedereen team kijkt dus naar zijn eigen deel, maar de misbruikroute ontstaat in de samenhang.
Daarom is businesslogica zo belangrijk bij een webshop pentest. Je kijkt niet alleen naar techniek, maar ook naar hoe commerciële processen zich gedragen wanneer iemand bewust de grenzen opzoekt.
De impact van businesslogica-misbruik
De impact van businesslogica-misbruik is vaak zakelijk van aard.
Het gaat niet alleen om een technisch risico, maar om geld, voorraad, klantdata, retourkosten, betalingsverkeer en reputatie.
Een fout in kortingslogica kan structureel marge wegvreten. Een zwakke refundflow kan leiden tot financieel verlies. Een fout in autorisatie kan klantgegevens blootleggen. Manipulatie in orderstatussen kan leiden tot operationele chaos.
Het vervelende is dat dit soort misbruik niet altijd direct als aanval wordt gezien.
Een frauduleuze order kan prima lijken op een normale order. Het terugbetalen van een klant kan worden gezien als een normale actie. En een misbruikte kortingscombinatie lijkt op een legitieme actie.
Daardoor kan misbruik lang onder de radar blijven voordat iemand het patroon ziet.
Wat een webshop pentest anders doet
Een webshop pentest kijkt niet alleen naar klassieke technische kwetsbaarheden, maar ook naar de achterliggende processen van de webshop.
De tester onderzoekt hoe de webshop omgaat met bestellingen, betalingen, kortingen, accounts, rollen, retourneren, terugbetalingen en koppelingen met externe systemen.
Daarbij draait het niet om de vraag of een functionaliteit werkt, maar of die functionaliteit misbruikt kan worden.
Denk aan:
Wat gebeurt er als stappen in een andere volgorde plaatsvinden?
Worden bedragen en kortingen server-side gecontroleerd?
Is een orderstatus afhankelijk van een betaalbevestiging?
Kan een gebruiker acties herhalen die maar één keer toegestaan zouden moeten zijn?
Worden rechten gecontroleerd bij het opvragen van orderdetails en/of klantgegevens?
Dit soort vragen kun je niet goed beantwoorden met alleen een vulnerability scan.
Daarvoor moet een pentester de webshop gebruiken zoals een aanvaller of fraudeur dat zou doen: gecontroleerd, maar met aandacht voor afwijkend gedrag. In het artikel over wat er tijdens een pentest gebeurt leggen we breder uit hoe zo’n gecontroleerde test in de praktijk verloopt.
Wanneer businesslogica extra aandacht verdient
Niet elke webshop heeft hetzelfde risicoprofiel.
Een eenvoudige webshop met standaardprocessen en beperkte maatwerklogica vraagt om een andere aanpak dan een platform met klantaccounts, staffelprijzen, B2B-functionaliteit, abonnementen, kortingscodes, retourportalen of complexe integraties.
Businesslogica verdient vooral extra aandacht wanneer een webshop werkt met:
- meerdere soorten gebruikers of klantgroepen;
- kortingscodes, bundels of staffelprijzen;
- abonnementen of terugkerende betalingen;
- retouren, refunds of tegoedbonnen;
- koppelingen met fulfilment, voorraad of boekhouding;
- maatwerk checkout- of betaalflows;
- B2B-prijzen of klantgebonden voorwaarden.
Hoe meer regels en uitzonderingen, hoe groter de kans dat ergens een ongewenste route ontstaat.
Daarom is het verstandig om juist bij maatwerk en complexe commerciële processen verder te kijken dan alleen technische kwetsbaarheden.
Complexiteit heeft ook invloed op de pentest kosten, omdat het testen van businesslogica meer handmatige analyse vraagt dan standaard checks.
Webshopbeveiliging is meer dan techniek
Een veilige webshop draait niet alleen om gepatchte software, sterke wachtwoorden en bekende kwetsbaarheden.
Die basis moet op orde zijn, maar fraude ontstaat vaak op een ander niveau.
De vraag is niet alleen of iemand ongeautoriseerd toegang kan krijgen. De vraag is ook of een ingelogde gebruiker, klant of partner de bestaande functionaliteit kan gebruiken op een manier die niet bedoeld is.
Dat maakt businesslogica een kernonderdeel van webshopbeveiliging.
Een webshop kan technisch veilig lijken, maar alsnog kwetsbaar zijn voor misbruik van kortingen, betalingen, of retourzendingen.
Wil je weten of jouw webshop niet alleen technisch werkt, maar ook bestand is tegen realistisch misbruik van commerciële processen? Dan kan een gerichte pentest helpen om risico’s in betaalflows, kortingscodes, retourprocessen en accountfunctionaliteit concreet in kaart te brengen.