Datalek voorkomen in je webshop: wat elk bedrijf moet weten
Gepubliceerd
Leestijd8 mins
Een onbedoelde ontdekking tijdens een prijsvergelijking bracht een datalek aan het licht bij een grote Nederlandse webshop. Klantgegevens zoals e-mailadressen, namen en ordernummers werden onzichtbaar meegestuurd met productreviews, toegankelijk via netwerkverkeer zonder dat dit op de pagina zichtbaar was. Dit type fout, bekend als overmatige gegevensblootstelling, komt vaak voor en ontstaat doordat systemen meer data versturen dan nodig.
Om dergelijke lekken te voorkomen, gelden drie kernlessen: beperk gegevensuitwisseling tot het strikt noodzakelijke volgens het Principle of Least Privilege, bereid je voor op incidenten met back-ups en protocollen, en zorg voor bewustwording op de werkvloer. Beveiliging is geen exclusieve IT-aangelegenheid, maar vereist praktische maatregelen zoals tweestapsverificatie, regelmatige updates en open communicatie over risico’s.
Onbedoeld klantgegevens gevonden op productpagina’s in een webshop
Ik was bezig met een het ophalen van prijzen voor verdere verwerking door de productpagina’s van een grote Nederlandse webshop uit te lezen. Dat was op zich een uitdaging, maar met een Python-webscraper kon ik van de ruim 600 artikelen prijzen, gewichten en afmetingen ophalen voor een spreadsheet. Tot me iets opviel wat er niet thuishoorde.
In de paginadata vond ik ook de productreviews – zoals “mooi zwembad, vijf sterren” – en bleek dat dat daarin de site méér gegevens verstuurde, waaronder e-mailadressen, volledige namen en ordernummers. Deze informatie was niet zichtbaar op de pagina, maar wel te zien in het netwerkverkeer tijdens de opbouw van de pagina.
Dat is een datalek. En het is een type fout dat verbazingwekkend vaak voorkomt — ook bij bedrijven die het goed voor elkaar denken te hebben. In deze blog leg ik uit wat er precies misging, waarom het zo makkelijk gebeurt, en wat jij als ondernemer kunt doen om een datalek in je eigen webshop te voorkomen.
Wat er onder de motorkap gebeurde
Een moderne webshop bestaat uit twee helften die met elkaar praten:
De voorkant: wat jij in je browser ziet (de ‘front-end’).
De achterkant: de server waar alle gegevens staan, inclusief de klantendatabase (de ‘back-end’).
Als je een productpagina opent, vraagt de voorkant aan de achterkant: “geef me de informatie van dit product om te laten zien.” Heeft een product reviews, dan worden die ook door de back-end meegegeven. De achterkant pakt ze uit de database en stuurt ze terug. Het probleem was dat de achterkant het hele databaserecord terugstuurde — inclusief het e-mailadres en ordernummer van de klant die de review schreef — terwijl de voorkant alleen de tekst en de sterren liet zien.
Iedereen met Chrome (of nog beter, Ungoogled Chromium) en een F12-toets op het toetsenbord kan de “bron” van een pagina inzien: de rauwe gegevens die de back-end stuurt, vóórdat de front-end besluit wat er wel en niet getoond wordt. De denkfout is begrijpelijk: “je ziet het toch niet, dus het is er niet.” Maar niet zien is iets anders dan er niet zijn. Het verbergen gebeurde pas op het laatste moment, in de browser — en dat is te laat. De gevoelige gegevens hadden de browser nooit mogen bereiken.
Beveiligingsmensen hebben hier een naam voor: overmatige gegevensblootstelling. Het staat met stip op 1 in de lijst van meest voorkomende API-fouten. De oplossing was in dit geval klein — een paar regels code waarmee de server alleen nog de velden meestuurt die echt nodig zijn. Maar je moet het wél wéten. Dus hier een paar “lessons learned”, zoals je na een incident doet om ervan te leren.
Les 1: geef nooit meer prijs dan nodig
Dit is misschien wel het belangrijkste principe uit dit hele verhaal, en het geldt voor élke koppeling in je bedrijf — je webshop, je boekhoudpakket, je nieuwsbriefsysteem, je voorraadbeheer.
Stuur en bewaar alleen wat je echt nodig hebt. Heeft de productpagina alleen de naam en de tekst van een review nodig? Stuur dan ook alleen dát. Niet het e-mailadres “voor het geval dat”. Niet het ordernummer “omdat het toch in de database staat”. Hoe minder gegevens er rondreizen, hoe minder er kan lekken.
Dit principe heeft een naam, en als je er één term uit deze blog onthoudt, laat het deze zijn: PoLP — het Principle of Least Privilege, oftewel het principe van de minste rechten. De regel is simpel: elke bestemming van informatie — of dat nu een stuk software is of een mens — krijgt precies datgene wat nodig is om de taak te doen, en geen letter meer.
Een review-pagina heeft genoeg aan de productnaam, het aantal sterren en de reviewtekst. Méér heeft hij niet nodig, dus méér krijgt hij niet — geen e-mailadres, geen bestelnummer. En het geldt net zo goed voor mensen: een baliemedewerker van een bank kan niet zomaar bij de beleggingsgegevens van private-bankingklanten, dat is voor het werk niet nodig.
Het gaat niet alleen om wie toegang heeft, maar ook hoe lang. Bij orderafhandeling heeft logistiek tijdelijk toegang om te verzenden, maar na afhandeling verdwijnt de order uit hun systeem. Alleen administratie behoudt toegang voor boekhouding, retouren of garantie. Onnodige toegang is als een open raam — een risico dat je vermijdt.
Ga dit eens na in je organisatie— wie kan bij welke bestanden, welke koppeling stuurt welke gegevens door, welke medewerker heeft toegang tot welk systeem — en je hebt het overgrote deel van de risico’s al afgedekt.
Les 2: ga er gewoon van uit dat het een keer misgaat
Dit advies kreeg ik ooit van een directeur van wie ik veel heb mogen leren: ga ervan uit dat er een keer iets misgaat, en zorg dat je er klaar voor bent.
Veel mensen denken: “beveiliging betekent dat er nóóit iets mag gebeuren.” Dat is niet haalbaar, en die gedachte verlamt alleen maar. Een risico tot nul terugbrengen is financieel en technisch onmogelijk — en dat hoeft ook niet.
Een lek, een gehackt wachtwoord, een verloren laptop — het gebeurt bij de beste bedrijven. Het verschil tussen een bedrijf dat het overleeft en een bedrijf dat eraan onderdoor gaat, zit niet in óf het gebeurt, maar in wat er klaarstaat als het gebeurt:
Heb je back-ups of snapshots die je daadwerkelijk kunt terugzetten (en heb je dat ooit getest)?
Weet je wie je belt als er iets misgaat?
Kun je terugzien wat er gebeurd is in je logbestanden?
Weet je wat je wettelijk moet doen bij een datalek? (Spoiler: je hebt 72 uur om het bij de Autoriteit Persoonsgegevens te melden.)
Dit klinkt misschien veel, maar het is precies hetzelfde als een brandblusser in je zaak. Je verwacht geen brand. Maar je hebt ‘m wel.
Les 3: beveiliging begint op de werkvloer, niet bij IT
Een hardnekkig misverstand is dat cybersecurity “iets technisch” is dat je aan de IT-afdeling of het bouwbureau overlaat. Maar de meeste incidenten beginnen helemaal niet bij ingewikkelde hackers — ze beginnen bij alledaagse dingen: een medewerker die op een neplink klikt, een wachtwoord dat hergebruikt wordt, een oude plugin die niemand heeft bijgewerkt, of een self-hosted wachtwoordkluis die per ongeluk over het hele internet bereikbaar is en gewoon in een zoekmachine te vinden (allemaal echte voorbeelden die ik in de praktijk ben tegengekomen).
Concreet, en zonder dat je een cent aan dure software hoeft uit te geven:
Gebruik een wachtwoordmanager en nooit twee keer hetzelfde wachtwoord. Dit is de goedkoopste, grootste beveiligingswinst die er bestaat. Kijk bijvoorbeeld eens naar Vaultwarden, een gratis en open source variant van Bitwarden.
Nog beter:
Zet tweestapsverificatie aan op alles wat het aanbiedt — je e-mail, je webshop-beheer, je bank. Kun je inloggen met eenmalige codes (OTP) of, nog beter, passkeys! Doe dat. Wachtwoorden onthouden of bijhouden is toch niet leuk.
Houd alles bijgewerkt. Verouderde software (denk: oude WordPress-plugins) is de meest gebruikte inbraakroute die er is.
Maak het bespreekbaar. Een team dat weet dat het oké is om te zeggen “ik klikte per ongeluk op iets raars” vangt problemen vroeg op. Een team dat dat verzwijgt uit schaamte, niet.
En als je niet weet waar je moet beginnen?
Dit verhaal begon toen ik toevallig iets zag en het netjes meldde. Maar je wilt natuurlijk niet afhankelijk zijn van het toeval dat een vriendelijke voorbijganger jouw lek opmerkt voordat iemand met slechte bedoelingen dat doet.
Ik help ondernemers — webshops, MKB-bedrijven, eigenlijk iedereen met klantgegevens — om hier grip op te krijgen. Geen eindeloze rapporten of dikke slidedecks, maar een praktische blik: waar staan je gegevens, wat reist er rond, wat is er nodig om AVG-proof te zijn, en wat zijn de paar dingen die je nú moet regelen. Een soort APK voor je digitale zaak.
Wil je het liever zelf uitzoeken? Helemaal top — daar word ik alleen maar blij van, en ik denk graag een keer vrijblijvend mee. Cybersecurity is geen geheime kunst; het is vooral een kwestie van de juiste gewoontes en weten waar je op moet letten.
Heb je een webshop of bewaar je klantgegevens en wil je gewoon even weten of het goed zit? Bel of mail me. Dan kijken we samen of er ergens een digitaal raam openstaat en je kostbare gegevens op de tocht staan.
Boyd is bezig met de certificering Certified in Cybersecurity (CC) van (ISC)² en helpt ondernemers onder andere met AVG-vraagstukken, digitale autonomie en soevereiniteit door self-hosting en EU-based IT-oplossingen.
We gebruiken cookies en vergelijkbare technieken om onze website goed te laten werken. We bewaren kleine bestandjes op je apparaat, en we meten hoe bezoekers onze site gebruiken.
Wil je ons ook toestemming geven voor statistieken, voorkeuren en reclame? Dan kun je dat hieronder aangeven. Je kunt je keuze later altijd veranderen.
Functioneel
Altijd actief
Deze cookies zijn nodig om de website goed te laten werken, zoals antispamdetectie.
Voorkeuren
Deze cookies onthouden algemene voorkeuren zoals taal en kleurweergave om de website prettiger te laten werken.
Anonieme statistieken
Deze cookies worden gebruikt om anonieme statistieken te verzamelen en de website te verbeteren.Deze helpen ons te begrijpen hoe bezoekers de site gebruiken. Zo kunnen we verbeteren wat goed werkt — helemaal anoniem, dus zonder dat we weten wie je bent.
Marketing
Deze cookies worden gebruikt voor reclame die beter bij je past.