Lovable-apps lekken klantdata: wat het onderzoek van Crissy Field en Handelsblatt laat zien.

Op 2 november 2026 publiceerde Handelsblatt-journalist Lina Knees een onderzoek naar apps die met Lovable zijn gebouwd. Het Hamburgse onderzoeksbureau Crissy Field deed het technische werk en publiceerde daarna een rapport met bijgewerkte cijfers. De uitkomst: in duizenden apps waren persoonsgegevens op te vragen door iedereen die de website bezocht.

Wat hebben de onderzoekers gevonden?

Het onderzoek verliep in twee stappen. Eerst zochten de onderzoekers passief in het open webarchief Common Crawl naar Lovable-projecten uit de periode december 2025 tot september 2026. Daarna deden ze bij een deel van die apps gerichte leesverzoeken, met dezelfde sleutel die de app zelf naar elke bezoeker stuurt. Ze lazen alleen, wijzigden niets en downloadden de datasets niet volledig.

Dat de records bij het laden meekomen, is op zich geen probleem. Een webshop laat ook producten zien zonder dat je inlogt. Het probleem zit in de laatste regel: met een paar extra leesverzoeken kwam er veel meer uit de database dan de bedoeling was.

Wat er op straat lag

Crissy Field noemt geen namen van apps, maar beschrijft wel wat het vond:

• Een dienstverlener met meer dan 1.000 records met paspoortgegevens: paspoortnummers, vervaldata en nationaliteiten.
• Een Duits lifestyleforum met ruim 80.000 profielen (namen, e-mailadressen, geboortedata) en meer dan 200.000 chatberichten.
• Evenementen- en restaurantplatforms met tienduizenden bestellingen, inclusief telefoonnummers, adressen, betaalinformatie en geldige ticketcodes.
• Een vastgoedbeheerder met AI-samenvattingen van interne e-mails over huurders, eigenaren en zakenpartners.
• Contracten, facturen, fotoalbums en interne WhatsApp-gesprekken. In één geval waren 280.000 verstuurde klantmails in te zien.

Of iemand die data heeft misbruikt, konden de onderzoekers niet vaststellen. Ze publiceren bewust niet hoe ze erbij kwamen.

Wat de 30% wél en níét betekent

In de berichtgeving circuleert het getal 30%. Dat is 7.403 gedeeld door 24.664: het deel van de nader bekeken websites waar e-mailadressen opvraagbaar waren. Crissy Field schrijft er nadrukkelijk bij dat dit geen bevestigd lekpercentage is, en dat de steekproef uit Common Crawl niet representatief is voor alle Lovable-apps. Een e-mailadres kan ook een openbaar contactadres of testdata zijn. Omgekeerd vallen records zonder e-mailadres, zoals paspoortnummers zonder mailadres erbij, buiten de telling. De onderzoekers noemen hun aantallen daarom eerder een ondergrens dan een precieze meting.

Eerlijk blijven over dit getal is belangrijk. Wie "30% van de Lovable-apps lekt" roept, overdrijft. Wie het onderzoek afdoet als een paar losse gevallen, onderschat het. Duizenden apps met echte klantdata is ernstig genoeg.

Hoe kan dit gebeuren?

Lovable bouwt apps vaak op Supabase. In die opzet praat de browser van de bezoeker rechtstreeks met de database. De sleutel die daarvoor nodig is, staat in de code van de website en is dus voor iedereen zichtbaar. Supabase zegt zelf dat dit veilig is, mits je Row Level Security aanzet: regels per tabel die bepalen wie welke rijen mag zien.

Staat RLS uit, of staat er een regel als "iedereen mag alles lezen", dan is die publieke sleutel genoeg om de hele tabel op te vragen. Volgens The CyberSec Guru ging het precies daar mis: tabellen die door AI-agents waren aangemaakt zonder RLS, gecombineerd met ruime standaardrechten voor anonieme bezoekers. Er is geen lek in de databasesoftware zelf gebruikt. Hetzelfde patroon werd in 2025 al beschreven in CVE-2025-48757.

In een Supabase-app is Row Level Security geen extra beveiligingslaag. Het is de enige.

Lovable heeft inmiddels een ingebouwde security scan en een AI-reviewer die op dit soort fouten controleren. Dat helpt. Maar de voorwaarden van Lovable leggen de verantwoordelijkheid voor de app en de data bij de klant. Crissy Field wijst op die spanning: de marketing suggereert dat je geen technische kennis nodig hebt, terwijl de verantwoordelijkheid juist bij jou ligt.

Niet de eerste keer: het incident van april 2026

Lovable lag een half jaar eerder ook al onder vuur. In april 2026 meldde een onderzoeker onder de naam @weezerOSINT een BOLA-fout (Broken Object Level Authorization): de server controleerde niet of je de eigenaar was van het project dat je opvroeg. Volgens The Register kon de onderzoeker met een gratis account in een paar API-aanroepen de broncode, AI-chats en klantdata van andermans publieke projecten inzien. Uit die broncode haalde hij ook database-credentials. Volgens de onderzoeker ging het om projecten van vóór november 2025.

De reactie van Lovable maakte het erger. Het bedrijf noemde het zichtbaar zijn van code van publieke projecten eerst "intentional behavior" en ontkende een datalek. Later bleek dat een wijziging in februari 2026 per ongeluk de chats van publieke projecten weer openzette. De meldingen via het bugbountyprogramma waren gesloten, volgens Lovable omdat de partners bij HackerOne dachten dat dit zo hoorde. Halborn beschrijft hoe die fout eerst alleen voor nieuwe projecten werd gerepareerd, terwijl bestaande projecten openstonden tot een tweede melding.

Dat is een ander soort fout dan die uit het Handelsblatt-onderzoek, maar het patroon is hetzelfde: autorisatie, de vraag "mag deze persoon dít zien?", werd niet goed gecontroleerd.

Waarom AI-gegenereerde apps hier vaker last van hebben

Lovable, Bolt en v0 zijn indrukwekkend. Je beschrijft wat je wilt en binnen een uur staat er een werkende app. Het probleem is niet dat de AI slechte code schrijft. Het probleem is dat de AI bouwt wat je vraagt, en dat beveiliging zelden in die vraag zit.

"Maak een app waar klanten tickets kunnen kopen" levert een app op waar klanten tickets kunnen kopen. Of klant A de tickets van klant B kan opvragen, komt in die vraag niet voor. Een ervaren ontwikkelaar stelt die vraag automatisch, omdat hij weet hoe het misgaat. Wie geen ontwikkelaar is, weet niet dat die vraag bestaat.

Drie dingen controleert een ontwikkelaar standaard, en vergeet een AI-tool als je er niet om vraagt:

• Authenticatie: wie ben je? Is inloggen verplicht voor alles wat niet openbaar hoort te zijn?
• Autorisatie: wat mag jij zien en wijzigen? Ziet een klant alleen zijn eigen bestellingen, en een medewerker alleen zijn eigen klanten?
• Datatoegang: welke gegevens verlaten de server? Gaat er niet meer naar de browser dan nodig is?

Dit is geen verhaal tegen AI. Wij gebruiken zelf dagelijks AI bij het bouwen. Maar AI is gereedschap, geen ontwikkelaar. Het schrijft code. Begrijpen wat die code doet, en wat ze níét doet, blijft mensenwerk.

Hoe wij dit in Laravel aanpakken

Bij een maatwerkapplicatie in Laravel praat de browser nooit rechtstreeks met de database. Elk verzoek gaat via de server, en daar beslist de code wat je terugkrijgt. Toegang regelen we met policies: per model leggen we vast wie iets mag bekijken, aanmaken, wijzigen of verwijderen. Vergeten we een regel, dan krijg je standaard niets te zien in plaats van alles.

Daar komen een paar vaste gewoontes bij:

• Queries filteren standaard op eigenaar of organisatie, zodat je niet per scherm hoeft te onthouden dat klant A niet bij klant B mag.
• Tests die autorisatie controleren: voor gevoelige routes schrijven we een test die bewijst dat een andere gebruiker een 403 of 404 krijgt.
• Alleen de velden die nodig zijn gaan naar de browser, via API Resources in plaats van complete database-rijen.
• Geheimen blijven op de server: databasewachtwoorden en API-sleutels staan nooit in code die de browser ziet.

Lees meer over onze aanpak op de pagina Security & vertrouwen en in het artikel over security by design in Laravel.

Heb je een Lovable-app? Doe dit nu

• Controleer RLS op elke tabel in het Supabase-dashboard. Een tabel zonder RLS is voor iedereen leesbaar.
• Lees de policies. RLS aan met een regel die alles toestaat, is net zo open als RLS uit. Een goede policy filtert op de ingelogde gebruiker.
• Test het als buitenstaander: log uit, of log in als een tweede testaccount, en kijk wat je nog kunt zien.
• Zet je project op privé als het nog op publiek staat, en zet geen wachtwoorden of API-sleutels in de chat met de AI.
• Herhaal de controle na elke grote wijziging. Een nieuwe tabel die de AI aanmaakt, heeft niet vanzelf de juiste regels.
• Denk aan de AVG: staan er persoonsgegevens open, dan kan dat een meldplichtig datalek zijn.

Crissy Field zegt het zelf ook: automatische controles zijn geen vervanging voor een beoordeling door een specialist. Een scanner ziet of RLS aanstaat, maar niet of de regels passen bij hoe jouw bedrijf werkt.

Mijn kijk op dit onderzoek

Ik vind Lovable een knap product. Ik zie ondernemers er in een middag iets mee bouwen waar ze vroeger maanden op wachtten. Daar is niets mis mee, zolang het een prototype blijft.

Het gaat mis op het moment dat dat prototype stilletjes productie wordt. Er komen echte klanten in, echte bestellingen, soms echte paspoortnummers. Niemand heeft op dat moment de vraag gesteld: wie kan dit allemaal zien? Dat is geen domheid. Je weet niet dat je die vraag moet stellen als je nooit hebt gezien hoe het misgaat.

Dat is precies het verschil tussen code genereren en software bouwen. Ik laat AI elke dag code schrijven. Maar ik lees wat er staat, ik weet welke vragen ik moet stellen, en ik schrijf tests die bewijzen dat klant A niet bij de gegevens van klant B kan. Dat laatste doet geen enkele tool vanzelf.

— Jasper

Zo helpt Coding Agency hierbij

Draait je bedrijf op een app uit Lovable, Bolt of v0? Met een technical assessment controleren we authenticatie, autorisatie, databasetoegang en AVG-risico's, en je krijgt een rapport met wat er moet gebeuren. Wil je verder dan een prototype, dan bouwen we je app opnieuw als maatwerk in Laravel, met beveiliging die vanaf de eerste dag is ingebouwd. Lees ook wat eerdere onderzoeken naar vibe-coded apps vonden.

Neem contact op voor een vrijblijvend gesprek.