Direct naar inhoud

Open databases in gevibecodede apps: wat de lekken van het afgelopen jaar je leren

In het kort

Onderzoekers vonden het afgelopen jaar steeds hetzelfde lek in apps die met AI gebouwd zijn: een database zonder toegangsregels. Wat dat is en wat het voor jouw app betekent.

Iemand werkt aan code op een laptop

Het afgelopen jaar vonden beveiligingsonderzoekers keer op keer hetzelfde probleem in apps die met AI gebouwd zijn. Niet een slimme hack, maar een database die voor iedereen open stond. In dit stuk lees je wat er gevonden is, waarom het zo vaak gebeurt en wat het voor jouw app betekent.

Wat is er gevonden?

Op 29 oktober 2025 publiceerde beveiligingsbedrijf Escape een onderzoek naar 5.600 gevibecodede apps (opent in een nieuw tabblad)1 die openbaar online stonden. Het ging vooral om apps van Lovable, maar ook van Base44, Create.xyz en Bolt. Escape vond meer dan 2.000 ernstige kwetsbaarheden, meer dan 400 gelekte geheime sleutels en 175 gevallen waarin persoonsgegevens open lagen, zoals medische gegevens en rekeningnummers. Een kwetsbaarheid is een zwakke plek waardoor iemand bij gegevens of functies kan die niet voor hem bedoeld zijn.

Op 2 februari 2026 beschreef beveiligingsbedrijf Wiz een lek bij Moltbook (opent in een nieuw tabblad)2, een sociaal netwerk voor AI-agents dat volgens de maker volledig met AI gebouwd was. Via een sleutel in de code van de website kon iedereen de hele database lezen én aanpassen. Daarin stonden onder meer 1,5 miljoen API-sleutels en ongeveer 35.000 e-mailadressen. Moltbook dichtte het lek binnen enkele uren na de melding.

Waarom gaat het steeds op dezelfde plek mis?

Veel AI-bouwtools gebruiken Supabase als database. Supabase werkt met twee soorten sleutels. De publieke sleutel staat altijd in je website. Dat is zo bedoeld en op zich geen probleem. De geheime sleutel mag nooit in de browser terechtkomen.

De publieke sleutel is alleen veilig als elke tabel toegangsregels heeft. Die regels heten Row Level Security (RLS): per rij in de database leg je vast wie hem mag lezen of wijzigen. Bijvoorbeeld: "een gebruiker ziet alleen zijn eigen bestellingen". De documentatie van Supabase (opent in een nieuw tabblad)3 is er duidelijk over. Zet RLS aan op elke tabel die via de API bereikbaar is. Een tabel zonder RLS is te lezen en te wijzigen door iedereen die toegang heeft tot die API.

Bij Moltbook en bij een groot deel van de apps uit het onderzoek van Escape ontbraken die regels. Je app werkt dan gewoon. Je merkt niets, tot iemand de publieke sleutel uit je website haalt en zelf vragen stuurt naar je database.

Dat gebeurt makkelijk bij vibecoden. De AI bouwt wat je vraagt, en je vraagt om functies, niet om toegangsregels. Een app die er goed uitziet, is daarom nog geen veilige app.

Wat doen de tools eraan?

De tools nemen het probleem serieuzer dan een jaar geleden. Lovable draait volgens de eigen documentatie (opent in een nieuw tabblad)4 bij elke publicatie automatisch een snelle scan. Die scan kijkt onder meer naar tabellen zonder toegangsregels per rij. Daarnaast is er een diepere scan die je hele code naloopt op onder andere gelekte sleutels en onbeveiligde toegang.

Dat helpt, maar een scan vindt niet alles. Hij weet niet welke gegevens in jouw app van wie zijn. Of "iedereen mag alle profielen zien" klopt, kun alleen jij beoordelen.

Wat betekent dit voor jou?

Heeft je app inloggen of opgeslagen gegevens, dan is dit de eerste plek om naar te kijken. Aan de buitenkant zie je het niet: je app werkt gewoon, ook als iedereen bij alles kan.

Wat er moet gebeuren, in gewone taal:

  • Elke tabel moet toegangsregels hebben, en die moeten kloppen. Een regel die alles toestaat, is net zo open als geen regel.
  • Geheime sleutels horen alleen op de server. Denk aan de service role-sleutel van Supabase en sleutels van betaaldiensten of AI-diensten.
  • Een scan van je tool is een begin, geen eindoordeel. Een groen vinkje bij publiceren zegt niet dat de regels passen bij wie wat mag zien in jouw app.
  • Lekken er persoonsgegevens, dan moet je dat mogelijk melden bij de Autoriteit Persoonsgegevens. Lees daarover meer bij privacy.

Meer uitleg over toegangsregels en geheime sleutels vind je bij beveiliging en data.

Dit nalopen vraagt kennis van de database, en dat hoef je niet zelf te doen. We kijken elke tabel en elke sleutel in je app na, zetten de regels zo dat iedereen alleen ziet wat van hem is, en testen dat als buitenstaander met een tweede account. Twijfel je of jouw app open staat? Vraag een gratis adviesgesprek aan.

Gecontroleerd op 6 oktober 2026.

Bronnen

  1. escape.tech een onderzoek naar 5.600 gevibecodede apps (opent in een nieuw tabblad) Geraadpleegd op 24 september 2026
  2. wiz.io een lek bij Moltbook (opent in een nieuw tabblad) Geraadpleegd op 24 september 2026
  3. supabase.com De documentatie van Supabase (opent in een nieuw tabblad) Geraadpleegd op 24 september 2026
  4. docs.lovable.dev de eigen documentatie (opent in een nieuw tabblad) Geraadpleegd op 24 september 2026

Vibecodechecker legt uit en geeft geen juridisch of fiscaal advies. We controleren elke regel tegen de officiële bron en zetten de datum erbij. Zo schrijven we.

Meer nieuws

Al het nieuws
  1. ACM controleert toegankelijkheid van webwinkels: geldt dat ook voor jouw app?

    De ACM vond dat 61 procent van de grootste webwinkels niet toegankelijk is. Sinds 28 juni 2025 is dat verplicht voor veel online diensten. Wat betekent dat voor jou?

    • 4 min lezen
    • 3 bronnen
    Iemand werkt op een laptop
  2. AI-verordening: wat de regels sinds 2 augustus 2026 betekenen voor je app met AI

    Sinds 2 augustus 2026 gelden de transparantieregels van de AI-verordening. Zit er een chatbot of AI-functie in je app, dan moet je gebruiker dat weten.

    • 4 min lezen
    • 5 bronnen
    Iemand gebruikt een app op een telefoon