Is je AI-gebouwde app veilig voor echte klanten? 9 checks

Een app die je met Lovable, Bolt of Cursor hebt gebouwd voelt af zodra hij doet wat je wilde. Dat is precies het probleem: beveiliging is het enige onderdeel waarvan je het ontbreken niet merkt. Alles blijft werken. Er komt geen foutmelding als iedereen bij alle gegevens kan, want jij bent op dat moment de enige die inlogt.

Hieronder negen checks die je zelf kunt doen, zonder developer en zonder de code te begrijpen. Ze staan op volgorde van hoe vaak ik ze misgaan zie. De eerste drie zijn de checks die er echt toe doen; kom je daar niet doorheen, dan zijn de andere zes nog niet aan de orde.

1. Staan er sleutels in je browser?

Open je app, druk op F12, ga naar het tabblad Network en klik ergens in je app. Kijk in de verzoeken die verschijnen naar de headers en de inhoud. Zie je iets dat lijkt op een lange sleutel met het woord service, secret, admin of private erin, dan heb je een probleem: alles wat de browser verstuurt kan een bezoeker lezen. Een publieke sleutel hoort daar wel te staan, een geheime nooit.

Dit is de meest voorkomende fout in AI-gebouwde apps, omdat de snelste manier om iets werkend te krijgen nu eenmaal is om de machtige sleutel te gebruiken. Werkt meteen, en het staat vervolgens voor iedereen te lezen.

2. Kan gebruiker A bij de gegevens van gebruiker B?

Maak een tweede account aan met een ander e-mailadres. Log daarmee in en probeer bij de gegevens van het eerste account te komen: verander een cijfer in de URL, of open een detailpagina waarvan je het adres kent. Zie je iets dat je niet mag zien, dan zit de afscherming alleen in het scherm en niet in de database.

Bij Supabase heet het mechanisme dat dit hoort te voorkomen Row Level Security. Het staat standaard aan bij nieuwe tabellen, en het wordt tijdens het bouwen net zo standaard uitgezet omdat het in de weg zit. Wat er dan gebeurt, weet alleen degene die het uitzette.

3. Wordt de prijs op de server berekend?

Verkoopt je app iets, dan is dit de check die geld kost als het antwoord nee is. Zoek in het Network-tabblad het verzoek dat de bestelling of de betaling start. Staat het bedrag daarin, verstuurd vanuit de browser, dan kan iemand dat bedrag aanpassen voordat het verstuurd wordt. Het hoort andersom: de browser stuurt wát er besteld is, de server bepaalt wat dat kost.

4. Kun je zien wie wat heeft gedaan?

Vraag jezelf af hoe je erachter komt dat er gisteren iets is verwijderd, en door wie. Is het antwoord dat je dat niet kunt zien, dan heb je geen logboek. Dat is te overzien zolang het goed gaat, en het is het verschil tussen een vervelende ochtend en een onoplosbare situatie zodra er iets misgaat.

5. Is er een back-up, en is die ooit teruggezet?

Bijna iedereen heeft een back-up omdat de hostingpartij die automatisch maakt. Bijna niemand heeft ooit geprobeerd er een terug te zetten. Een back-up die je nooit hebt uitgeprobeerd is een aanname, geen voorziening. Zet er één keer één terug in een lege omgeving en je weet het.

6. Kan iemand het formulier duizend keer versturen?

Elk openbaar formulier en elk openbaar adres waar je app naar luistert is een uitnodiging. Zonder een limiet op het aantal verzoeken kost een simpel script je een volle mailbox, een volgelopen database of een rekening bij de dienst die je per verzoek betaalt. Bij AI-functies is dat laatste geen theorie: die rekening loopt hard.

7. Zit je test-data door je echte data?

• Draait er één omgeving voor testen en echt gebruik?
• Staan er nog accounts in met namen als test, asdf of jouw eigen adres met een plusje?
• Kun je iets uitproberen zonder dat een klant het kan zien?

Drie keer het verkeerde antwoord betekent dat je alleen nog buiten kantooruren durft te werken. Dat is geen beveiligingsgat, maar het leidt er wel toe: wie bang is om iets aan te raken, laat updates liggen.

8. Weet je wat er met persoonsgegevens gebeurt?

Waar staat je database fysiek, welke externe diensten krijgen gegevens van je gebruikers te zien, en heb je met die partijen iets op papier staan? Voor de meeste kleine apps is dit sneller opgelost dan gevreesd, hosting in de EU en een verwerkersovereenkomst bij twee of drie leveranciers, maar het gebeurt zelden vanzelf, en een AI-tool vraagt er niet naar.

9. Kun je terug naar de versie van gisteren?

Als de aanpassing van vanmiddag iets sloopt, hoe ben je dan binnen tien minuten terug bij hoe het vanochtend was? Kun je die vraag niet beantwoorden, dan bestaat er geen echt versiebeheer, alleen een lijst met prompts. Dit is het punt waarop doorbouwen langzamer wordt dan opnieuw beginnen, en het is te repareren op een middag.

Beveiliging is het enige onderdeel van je app waarvan het ontbreken niet tot een foutmelding leidt. Daarom vind je het pas als je er expliciet naar zoekt.

Hoe vaak gaat dit mis in echte Lovable-apps?

Vaker dan je zou hopen, en dat zeg ik niet op gevoel. In maart 2025 scande onderzoeker Matt Palmer 1.645 apps die met Lovable waren gebouwd. Bij 170 daarvan, ruim 10 procent, kon een buitenstaander zonder in te loggen bij de database: 303 lekke endpoints in totaal. Het lek kreeg een officieel nummer, CVE-2025-48757 (bron: Palmers verklaring en de CVE-registratie). Lovable betwist dat het een fout in hun product is, omdat elke maker zelf verantwoordelijk is voor zijn data. Dat mag zo zijn, maar je klanten maakt het niet uit wiens schuld het is.

In oktober 2025 publiceerde securitybedrijf Escape een scan van ruim 5.600 openbare apps die met vibecode-platforms zijn gebouwd: meer dan 2.000 kwetsbaarheden, meer dan 400 blootgestelde geheime sleutels en 175 gevallen van zichtbare persoonsgegevens, waaronder medische gegevens en IBAN's (bron: het methodologie-artikel van Escape).

En in februari 2026 schreef The Register over een app die Lovable zelf uitlichtte op zijn Discover-pagina. Een onderzoeker vond er 16 kwetsbaarheden in en 18.697 gebruikersrecords die open lagen. De oorzaak was geen ontbrekende beveiliging, maar beveiliging die precies verkeerd om stond: ingelogde gebruikers werden geweigerd, anonieme bezoekers kwamen erin.

Waarom de scanner van Lovable dit niet vangt

Sinds juni 2026 draait Lovable automatisch een snelle securityscan zodra je het publiceervenster opent. Die kijkt onder meer of je tabellen per rij zijn afgeschermd en of er regels zijn die iedereen doorlaten. Goed dat die er is. Maar een scanner ziet dát er een regel bestaat, niet of die regel klopt. Een regel die precies de verkeerde groep binnenlaat, zoals bij die app uit The Register, ziet er voor een scanner net zo netjes uit als een goede. Lovable schrijft zelf in de documentatie dat de scans geen volledige beveiliging kunnen garanderen.

Daarom doe je check 2 hierboven met de hand: twee accounts en één uitgelogd browservenster. Dat is de enige test die vraagt wat er echt gebeurt in plaats van wat er ingesteld staat. Krijg je bij een nieuwe tabel juist een foutmelding in plaats van te veel data, dan lees je in waarom je nieuwe Supabase-tabel een permissiefout geeft wat er aan de hand is.

En als er checks niet doorheen komen?

Dan is dat geen reden om weg te gooien wat je hebt. Wat je gebouwd hebt is een werkend antwoord op de vraag wat je eigenlijk wilde, en dat is het deel waar de meeste projecten op stuklopen. De negen punten hierboven zijn stuk voor stuk op te lossen zonder dat de app eruit hoeft te zien zoals hij eruitziet.

De volgorde waarin ik ze zelf aanpak: eerst de sleutels uit de browser, dan de rechten op de database, dan de bedragen naar de server. Die drie samen zijn meestal een kwestie van dagen en halen het grootste risico weg. De rest kan daarna, in het tempo dat bij je groei past.

Die eerste twee hebben een eigen artikel: mijn API-sleutels staan in de frontend en waarom kunnen mijn gebruikers elkaars gegevens zien. Wil je de negen punten niet zelf aflopen, dan is dat precies wat een vibecode-assessment voor je doet.

Wil je eerst alleen weten waar je staat, begin dan met de gratis vibecode-scan. Ik kijk tien minuten naar je project en je krijgt een eerlijk oordeel terug.