Bol-klanten stuitten door incident op afrekenpagina van andere klant - update

Enkele tientallen klanten van webwinkel bol kwamen afgelopen weekend door een 'technisch incident' op de afrekenpagina van een andere klant terecht. Hierbij werden de naam, adresgegevens en producten in de winkelwagen van die andere klant zichtbaar.

Bol bevestigt het datalek aan Tweakers, nadat deze site navraag deed naar aanleiding van een melding van een getroffen klant. "Afgelopen weekend heeft zich bij bol een technisch incident voorgedaan waarbij in een pieksituatie enkele klanten een pagina te zien kregen die bestemd was voor een andere klant", laat een woordvoerder van de webwinkel weten. Bol doet nog onderzoek naar de precieze omvang van het incident, maar verwacht dat 'enkele tientallen' klanten zijn getroffen.

Het incident is volgens de woordvoerder 'direct na ontdekking onderzocht en verholpen'. Ook heeft de webwinkel de Autoriteit Persoonsgegevens op de hoogte gesteld. "We nemen dit uiteraard zeer serieus en staan in contact met klanten die zich over dit onderwerp bij ons melden."

De woordvoerder geeft geen verdere informatie over het technische incident. Ook is het niet duidelijk welke pagina klanten te zien kregen. De getroffen klant liet aan Tweakers weten dat diegene zaterdagavond in de winkelwagen van een andere klant terechtkwam. Daar zag hij naar eigen zeggen de naam en adresgegevens van de andere klant en de producten die in het winkelmandje zaten. Bol heeft dat vooralsnog niet bevestigd.

Update, 11 maart: Bol heeft tegenover Tweakers verduidelijkt dat klanten door het incident op de afrekenpagina van een andere klant belandden en dat daarbij naw-gegevens zichtbaar waren. "Het was niet mogelijk om namens iemand handelingen te verrichten. Technisch gezien bleef de klant in ons systeem namelijk dezelfde persoon."

Afbeelding ter illustratie.

Reacties (55)

[iAR]

Ik vind dit altijd wel boeiend: hoe kan zoiets?

[jrswgtr]

Het zou ook kunnen dat er Varnish cache gebruikt wordt. Normaal gesproken worden persoonlijke pagina's daarvan uitgesloten maar een verkeerde aanpassing van de policy (vcl) er toch gecachede pagina's geserveerd worden.

[dakathefox]

Inderdaad. De enige keer dat ik dit ooit heb meegemaakt was bij het gebruik van Varnish.

[jrswgtr]

Het meest lastige bij Varnish vind ik dat het uitsluiten van paden in principe niet via de applicatie geregeld wordt maar in de VCL.

Als er dan nieuwe routes bijkomen in de applicatie die níet gecached moeten worden, dan moeten die ook aan de VCL toegevoegd worden, op serverniveau dus.

Daar kunnen best wat dingen misgaan als de communicatie tussen teams niet optimaal is.

[demianmonteverd]

Dit is mss de meest logische verklaring. Een cache op de winkelwagen die niet goed werkt/is ingesteld/werd exposed.

[Crim]

Bol gebruikt idd Varnish.

[djwice]

Je kunt een vary-header mee geven vanaf de backend waarmee je op de unieke klant header laat variëren, naast de juiste caching headers helpt dat ook tegen dit soort incidenten.

Juist ook met varnish. Als je dit slim inzet - zelfde techniek - kun je ook zo aanvallers op je varnish honeypot backend laten landen in plaats van op je echte backend.

Uiteraard moet je nooit na bijvoorbeeld een database restore reeds uitgegeven IDs opnieuw uitgeven als uniek.

De Vary HTTP-header is een mooi ding die al meer dan 25 jaar op alle servers geïmplementeerd is. Een wereldwijde standaard. Ik heb er voor een organisatie met tientallen miljoenen gebruikers zero-trust mee geïmplementeerd die soepel werkt ook met legendarisch oude systemen, zonder enige extra software installatie, geen agents niets. Een geen of een kleine configuratie aanpassing in de webservers was voldoende.
https://www.w3.org/Protoc...c2616-sec14.html#sec14.44

[Reactie gewijzigd door djwice op 10 maart 2026 21:52]

[ForReal]

Caching is idd een logische verklaring (varnish is maar één van de vele manieren om te cachen overigens).

En zo'n bug kan ook prima in lijn zijn met de verklaring "niet mogelijk om namens iemand handelingen te verrichten".

[genosis]

Een of andere cache laag die mismatched? Of een enorme klungel die id en iets van shopping_cart_id omwisselt?
Genoeg dingen die mis kunnen gaan.

[wiseger]

Precies, problemen met state hebben we al decennia, sinds we naar stateless middleware overgingen voor de schaalbaarheid. Alles in de header stoppen is vaak geen optie, want dan wordt die al snel te groot. Dus ontwikkeld men mechanismes om state toch ergens te cachen, zodat na het ontvangen van een nieuw request de state toch ergens vandaan gehaald kan worden. En daar is kennelijk iets misgegaan.

[iAR]

En toch snap ik dat niet, je (gu)id wisselen toch niet zo maar? Lijkt me al helemaal niet bij een groot bedrijf als bol.com

[Sleipnir]

Ach, tijdens de Kerst van 2015 gebeurde hetzelfde bij Steam, dus grootte maakt blijkbaar niet zo veel uit.

[Caelorum]

Valve heeft minder dan 400 medewerkers in dienst. Bol.com bijna het vijfvoudige.

[dakathefox]

Bol.com doet anno 2026 nog niet eens de omzet die Steam in 2015 maakte.

[Caelorum]

Wat is je punt? Bol.com heeft meer handjes en denktijd, dus ik zou verwachten dat ze het een stuk beter op orde hebben dan Valve.

Daarnaast is die medewerker hier ook iets goedkoper.

[dakathefox]

Meer handjes wil ook niet zeggen dat het dan een stuk beter op orde is. Het lijkt me sterk dat een heftruckchauffeur dit probleem had kunnen oplossen.

[R_Zwart]

Maar is dat niet het geval bij heel veel problemen? Er van uitgaan dat het helemaal niet zomaar kan. Er zullen altijd uitzonderlijke situaties kunnen voorkomen die niemand heeft vooraf heeft kunnen bedenken.

[genosis]

Nou, grote kans dat ze dat niet gebruiken dus..

[OGrasmachien]

Dit begrijp ik ook niet.
Sessions zijn een fundament in web development.
Hoezo kan een gebruiker de session van een andere klant overnemen?
Het enige wat ik me kan bedenken is dat er collisions zijn in de sessions ID's.
Maar dat lijkt me ook heel sterk.
Benieuwd of iemand hier wat meer inzicht in kan geven.

[demianmonteverd]

Bol heeft aardige schaal, dus collisions kunnen voorkomen. Dus als ze daar niet expliciet op checken kan dit dus gebeuren. Een race in de check, daar zijn ze dan misschien weer niet groot genoeg voor als het blijkbaar bij meerdere mensen is voorgekomen.

Het zou dus nog collision kunnen zijn. Maar zou het meeste inzetten nu op het ophalen van de gegevens voor het winkelwagentje op basis van de sessie. Of dat men het winkelwagentje resultaat cached en dat dat stukje niet goed is uitgewerkt/uitgedacht.

[uiltje]

Zoals een andere post al zei: sessies zijn zowel een fundament als een probleem voor schaalbaarheid. Dat betekend dat je natuurlijk de sessie op de client en backend server moet bewaren (bijvoorbeeld het tijdelijk locken van een product), en daartussen kan het fout gaan.

[Stemis]

in een pieksituatie enkele klanten een pagina te zien kregen die bestemd was voor een andere klant

Dit duidt waarschijnlijk op een hash collision. (Dit is pure speculatie, dus neem het met een korrel zout).

Het kan zijn dat er 'winkelmandjes' in een cache worden geladen. En bij verkeerd gebruik van bijv hash generatie, deze overschreven wordt met data van een andere klant. Dat zie je nog wel is voorkomen bij verkeerd gebruik van hash generators etc.

[Bedge85]

Ja dat zou kunnen. Een andere optie is een race-conditie die ergens speelt bij het verwerken van de sessies op de server.

[uiltje]

Als cryptograaf weet ik dat het kan, maar dan zou er eigenlijk al wat verkeerd moeten gaan in het design. Het zal wel iets met mapping te maken hebben van een hash naar de juiste data.

[Hathi]

Het exacte antwoord zal alleen iemand van de ontwikkelafdeling van bol je kunnen vertellen, maar mogelijk ging er iets niet goed met de sessies, waardoor je per ongeluk in de sessie van een andere klant terecht kwam.

[gimbal]

Hoe dan ook blijft het niet eenvoudig want stel dat het session pinning was wat uit stond terwijl het aan had moeten staan. Dan zou Pietje naar server A gestuurd moeten worden voor alle requests maar gaat eindelijk toch naar server B waar de sessie van Jantje nu toevallig dezelfde ID heeft.

Dat zou dan betekenen dat de gebruikte IDs bij lange na niet random genoeg zijn zodat het mogelijk is dat het opvragen van een session bij de verkeerde server een goede kans van slagen heeft. Ik kan me niet voorstellen dat dit enkel een configuratiefout is... de configuratiefout legt een dieper probleem bloot waar exploiters van smullen.

[demianmonteverd]

Dat is echt wel bizar, denk niet dat dit de oorzaak is. Een variant die op basis van jouw idee kunt bedenken is dat men de sessie op meerdere plaatsen uitgeeft maar niet goed (meer) salt (door upgrade van library oid) of er vroeger een hostname bij stopte of de hostname is hetzelfde geworden voor meerdere servers door een uitwijk actie, etc. Wellicht heeft men de hostnames aangepast of was er... een DNS(!) issue dat voorheen op een andere manier werd ondervangen. Het kan ook zijn dat men meerdere sessies cookies zette met dezelfde naam en dat er dan altijd een lege bij komt door een refactoring en dat alle lekken dezelfde klant hebben gezien. Etc.. Of de sessie cookie werd niet juist doorgeven bij het ophalen van de winkelwagen en je kreeg dan een 'willekeurige' terug op basis van de database/nosql implementatie (ik weet niet wat ze gebruiken voor de winkelwagen).

Interessant zou zijn om te weten te komen of men meerdere pagina's kon bezoeken en mutaties kon doen aan de winkelwagen of zag gebeuren. Ik werk niet bij Bol dus kan het niet uitzoeken wat er gebeurde, dus alles hierboven is speculatie. We weten te weinig om het te raden eigenlijk.

[Afvalzak]

Dat kunnen best veel redenen zijn.

Deze heb ik wel eens voorbij zien komen (gelukkig opgemerkt voor live gang )

- Issues met sessies waardoor deze bij de verkeerde personen worden gekoppeld.
- Caching in een loadbalancer die niet goed werkt waardoor gebruikers een cache zien van een andere user bijvoorbeeld.

maar er zijn vast nog tal van situaties te bedenken waar dit voor kan komen.

[fvanunen]

je hoort web caching normaliter zo te configureren dat het niet responses cached voor requests die met een cookie of een authorization gedaan zijn. Als je daarin niet consequent bent, dan kan het zijn dat iemand anders uit de cache een response krijgt die niet voor haar/hem bedoeld is. Dat zou een van de mogelijke oorzaken zijn.

[SampleUser]

Vaak komt dit door verkeerd afgestelde caching. Steam (online gameswinkel) had ook eens zoiets, hier is het leuk uitgelegd: YouTube: Seeing Other People's Steam Accounts: The Christmas Caching Catastrophe

[Aloy]

Je hebt al veel reacties gekregen maar ik wou toch ook even mijn idee geven. Mijn gevoel gaat uit naar een race conditie, helemaal omdat ze het hebben over dat het tijdens een piekmoment voor komt.

Een paar weken geleden had ik ook een race conditie bug gevonden in een relatief populaire GraphQL server / module framework. Wat daar gebeurde is dat wanneer 2 verschillende gebruikers de zelfde resource aanriepen op het juiste moment, de ene request de 'sessie ID' overschreef van de andere request. Aangezien Bol ook GraphQL lijkt te gebruiken, gaat natuurlijk meteen mijn gedachte ook daar heen.

[Omegium]

Jaren geleden ooit een vergelijkbare bug bij een bank gevonden en opgelost. Was erger dan dit, klanten zagen elkaars beleggingsportefeuille (maar konden niet elkaars geld uitgeven)

Uiteindelijke bug:

In java (spring) heb je een jdbcTemplate. Hier stop je een query in, en daarna een voor een de parameters (parameterized queries, om SQL injectie te voorkomen).

Maar deze jdbcTemplate was als een field aan een class toegevoegd, in plaats van voor iedere call een nieuwe te maken. Dit betekent dat het gedeeld wordt tussen de threads. Dus een klant kwam in een thread, de userId werd ingevuld, een andere thread kwam ook in de class terecht, nam de jdbcTemplate met de andere parameter, en riep de database aan. Kwam zeer zelden voor (de thread pool moest op exact het juiste moment wisselen) maar het kon wel. En het was niet te reproduceren, want als je het met de hand test kwam dit uiteraard nooit voor. Alleen als duizenden klanten het tegelijkertijd deden.

Dit soort bugs kunnen heel subtiel zijn en moeilijk te vinden.

[DjoeC]

Tja, er zijn veel manieren/fouten denkbaar waardoor dit kan maar de reden is vast een programmeur die nog niet wakker was, een AI die hallucineerde en een tester die een randgeval niet getest heeft. Het zijn gewoon dingen die gebeuren......

[PdeBie]

Vroeger gebeurde dit wel eens doordat het ID van de klant op de URL stond in de querystring, maar dit is tegenwoordig (gelukkig!) een stuk minder aan de orde.

De enige die het weten in dit geval zijn de developers.

[NicoHF]

Ben benieuwd of de getroffen klanten van het datalek op de hoogte gesteld gaan worden als dat überhaupt duidelijk is wie de getroffende zijn.

[Quintiemero]

Is ook niet verplicht.

[NicoHF]

Waarom zou het niet verplicht zijn?

Ze moeten zelf een inschatting maken en het kan dan wel dergelijk verplicht zijn om de betrokkene te informeren


https://www.autoriteitpersoonsgegevens.nl/themas/beveiliging/datalekken/datalek-wel-of-niet-melden


Als ik de uitzonderingen zo lees wanneer een organisatie de betrokkene NIET hoeft te informeren maak ik de conclusie op dat ze wel VERPLICHT zijn om de betrokkene te informeren.

Slachtoffers informeren niet nodig

In de AVG staan 3 situaties waarin u de slachtoffers mogelijk niet persoonlijk hoeft te informeren over het datalek:

1. Maatregelen vooraf

U heeft vooraf passende maatregelen genomen die de persoonsgegevens onbegrijpelijk maken voor onbevoegden, zoals versleuteling.

2. Maatregelen achteraf

U heeft achteraf maatregelen genomen die ervoor zorgen dat het datalek is beëindigd. En dat het hoge risico voor de slachtoffers zich waarschijnlijk niet (meer) voordoet.

Bijvoorbeeld wanneer u de persoon die toegang tot de persoonsgegevens heeft gehad, onmiddellijk heeft geïdentificeerd. En u actie heeft ondernomen voordat die persoon iets met de persoonsgegevens kon doen.

3. Onevenredige inspanning

Het individueel informeren van de slachtoffers vraagt een onevenredige inspanning van u. Bijvoorbeeld omdat u de contactgegevens van de slachtoffers bent kwijtgeraakt door het datalek. Of omdat de contactgegevens niet bekend zijn. 

U mag de slachtoffers dan ook informeren met een openbare mededeling of een soortgelijke maatregel. Bijvoorbeeld door een bericht te plaatsen op sociale media of in de lokale krant, in combinatie met een mededeling op uw website.

[Reactie gewijzigd door NicoHF op 10 maart 2026 20:12]

[Quintiemero]

De website van de van de AP is niet juridisch bindend. Betrokkenen informeren is alleen verplicht bij hoog risico. Dat is wat moet worden beoordeeld. De guidelines van de EDPB bieden meer handvatten. Maar zou even de wetteksten erbij pakken ipv verspelde versie van de AP.

Voorbeeld 1: logisch, dan is er geen risco.
Voorbeeld 2: idem.

Er zit nl nog veel ruimte tussen deze voorbeelden en hoog risico. Dat benoemde de AP niet. Let op: meldplicht bij betrokkene is minder snel van toepassing dan melden AP, vaak volstaat dat.

[Reactie gewijzigd door Quintiemero op 11 maart 2026 06:44]

[Finnrt]

Ik denk niet dat dat gaat gebeuren. Ik denk dat dit heel moeilijk te achterhalen is, vooral als het om een caching probleem gaat (wat ik wel verwacht).

[Robru1]

Het gaat tijd worden dat BOL. ook voor particulieren 2FA invoert.

Hmmm, 2FA is nu wel beschikbaar...

[Reactie gewijzigd door Robru1 op 10 maart 2026 16:20]

[R_Zwart]

En daarmee voorkom je softwarebugs?

[uiltje]

Ja, lijkt me ook sterk. Het zou per ongeluk zo kunnen zijn (andere manier van identificatie immers), maar het lijkt me behoorlijk onwaarschijnlijk.

[uiltje]

Identificatie na authenticatie gebeurd meestal met tokens. Die bevatten meestal geen data die direct op de 2FA is gebaseerd voor het bijhouden van de sessies zover ik kan nagaan. Zoals de andere post al aangeeft: dit staat zeer waarschijnlijk volledig los van dit probleem - hoewel een wijziging in het systeem natuurlijk altijd problemen kan veroorzaken.

[Reactie gewijzigd door uiltje op 10 maart 2026 16:32]

[kweenie]

Ik heb het ook gehad. Schrok er zo van dat ik vergat een screenshot te maken.

Zag idd adresgegevens van een andere, vrouwelijke, klant en een bunq bank rekening. Gelijk app afgesloten en niks besteld.

[TwiekertBOB]

Gebeurde dit in de App of via de website / browser?

[kweenie]

In de app

[Metal spoon]

Leuke afbeelding er bij gekozen wel

[Quoz]

Dit doet me denken aan een probleem wat github in 2012 ook had.Vanwege drukte was de communicatie tussen nodes slecht, en waren verschillende nodes dezelfde waardes aan het toevoegen voor een key die eigenlijk uniek zou moeten zijn. Deze keys werden in een Redis cache gebruikt. Het gevolg: sommige gebruikers van github kregen data van andere gebruikers te zien, omdat voor die gebruikers dezelfde key werd gebruikt in de cache.

https://github.blog/news-insights/github-availability-this-week/

Dit zou door een zelfde soort probleem kunnen komen - of door totaal iets anders.

[AvK]

Ja klopt, ik had dat ook..... Nu snap ik wat er gebeurd is. Vond het zo gek. Heb mijn laptop opnieuw opgestart (ja weet het, slaat nergens op) en weer naar Bol. Toen ging het goed.

[uiltje]

Och, op het reset knopje drukken is nog niet zo'n slechte oplossing. Het herstarten van de browser of kijken met een anoniem browser tabje lijkt me minder ingrijpend, maar als er verder niets open staat dan werkt een reset prima. Die paar extra seconden kan je wel missen.

[AvK]

Ja dat sowieso wel. Maar vond het zo gek en niet eens nagedacht, zal ik eens kijken wat ik allemaal kan zien. Het was meer een spontane reactie van 'Hee..... dat ben ik niet. Das gek. Mhhh.... ff opnieuw opstarten'

[shadowkid053]

Onlangs had Wehkamp dit overigens ook na een overbelasting van de site na een prijsfout die gemeld was op pepper.

[Microsoftman]

Nou dat gaat lekker de laatste tijd.

Er moet gewoon een professioneel security team alle bedrijven maar eens goed na laten kijken.

Want dit kan zo niet doorgaan!

Ik geef niemand de schuld maar voorkomen is beter dan genezen

[lighting_]

het komt wel vaker voor dan wij denken
Bank branche is een van de weinige die het op orde heeft.
Een lek is voor hen dan ook catastrofaal.

Zelfs bij nctv ging het mis.
https://nos.nl/artikel/25...-documenten-thuis-zegt-om

[_NooT_]

Het is maar de vraag of security experts dit hadden voorkomen. Websites en software zijn vaak zo complex dat het praktisch onmogelijk is om alle fouten te voorkomen.

Als ik een gokje mag wagen, vermoed ik dat er dubbele session ids zijn gegenereerd, mogelijk in combinatie met het cachen van requests.