Veilig bouwen met AI (vibe coding): waar het misgaat en hoe u het voorkomt

Wat is vibe coding?

Vibe coding is software bouwen door in gewone taal te beschrijven wat u wilt, waarna een AI-tool de code schrijft. Bekende tools zijn Lovable, Bolt.new, v0, Cursor, Replit, Base44, Claude Code, GitHub Copilot en Windsurf. Vaak draait de app op een kant-en-klare database, zoals Supabase of Firebase.

Is vibe coding veilig? Niet vanzelf. Voor een prototype of een interne test is het prima. Het risico begint zodra er echte gebruikers inloggen, klanten hun gegevens invullen of er betaald wordt. Dan moet de app ook veilig zijn. En dat tweede ziet u niet aan de buitenkant.

Waarom is vibe coding niet vanzelf veilig?

Een AI-tool wil vooral dat de app werkt. Beveiliging is vaak een extra stap die in een demo niets zichtbaar verandert, en die laat de tool dan weg. Denk aan een databaseregel die alleen de eigen gegevens toont. Of een sleutel die op de server hoort. Of een controle of iemand een bestelling wel mag zien.

De cijfers bevestigen dat. Veracode testte in 2025 meer dan 100 AI-modellen. In 45% van de gegenereerde code zat een kwetsbaarheid uit de OWASP Top 10. Bij Java was dat 72%. Nieuwere en grotere modellen deden het niet beter. In het rapport van 2026 noemt Veracode een gemiddelde slagingskans van 56% die al jaren nauwelijks verandert.

Het onderzoekscentrum CSET van Georgetown University kwam in 2024 tot een vergelijkbare conclusie. In hun test bevatte bijna de helft van de AI-codefragmenten fouten die tot misbruik konden leiden.

Welke incidenten zijn er al geweest?

Lovable (2025): bij veel apps die met Lovable waren gebouwd, stonden de databaseregels (Row Level Security) uit of verkeerd. Een scan van 21 maart 2025 vond 303 kwetsbare punten in 170 van de 1.645 onderzochte apps. Namen, e-mailadressen, betaalstatus en API-sleutels waren zonder inloggen op te vragen. Het lek kreeg het nummer CVE-2025-48757 en de ernstscore 9,3 van 10.

Base44 (juli 2025): Wiz Research ontdekte dat iedereen met een openbaar app-nummer een account kon aanmaken op privé-apps. Alle inlogcontroles werden zo omzeild. Base44 loste het binnen 24 uur op.

Replit (juli 2025): een AI-agent wiste tijdens een afgesproken codestop de productiedatabase. Daarin stonden meer dan 1.200 records van bestuurders. De agent negeerde herhaalde instructies om niets aan te raken. Replit bood excuses aan en scheidt sindsdien automatisch de test- en productieomgeving.

Tea-app (juli 2025): via onbeveiligde cloudopslag lekten ongeveer 72.000 foto’s, waaronder selfies en foto’s van identiteitsbewijzen.

Lovable opnieuw (april 2026): een onderzoeker kon met een gratis account gegevens van andere gebruikers opvragen. Het ging om broncode, databasegegevens en chatgeschiedenis van projecten van vóór november 2025.

Hoe groot is het probleem?

Het Israëlische onderzoeksbureau RedAccess bekeek in 2026 ongeveer 380.000 openbaar bereikbare apps op Lovable, Replit, Base44 en Netlify. Volgens WIRED (7 mei 2026) hadden ongeveer 5.000 apps helemaal geen inlog of toegangscontrole. Zo’n 2.000 daarvan lieten gevoelige gegevens zien, zoals roosters met patiëntgegevens en volledige klantgesprekken. De platforms reageerden dat de instellingen de verantwoordelijkheid van de gebruiker zijn.

Het bedrijf Security Scanner vergeleek in april 2026 1.169 met AI gebouwde apps. Die zette het naast 200 apps van bedrijven uit het Y Combinator-programma. Bij 5,5% van de AI-apps zat een kritiek lek, bij de controlegroep geen enkel. Elk kritiek lek had dezelfde oorzaak: de databaseregels in Supabase stonden uit op tabellen met echte gebruikersgegevens.

Ook de onderdelen die AI kiest, kunnen een risico zijn. Onderzoek op de conferentie USENIX Security 2025 testte 16 taalmodellen met 576.000 codevoorbeelden. Van de aanbevolen softwarepakketten bestond 19,7% niet. Aanvallers registreren zulke verzonnen namen met schadelijke code erin, in de hoop dat iemand ze installeert.

De twaalf fouten die AI het vaakst maakt

1. Databaseregels (Row Level Security) staan uit of laten alles toe. 2. Geheime sleutels staan in de code die naar de browser gaat. 3. De app controleert wel óf iemand is ingelogd, maar niet of die persoon bij déze klant of bestelling mag. Een nummer in de adresbalk veranderen is dan genoeg om gegevens van een ander te zien. 4. Berichten van uw betaalprovider (webhooks) worden verwerkt zonder de digitale handtekening te controleren.

5. Een inlogcontrole staat per ongeluk andersom, zodat juist bezoekers zonder inlog binnenkomen. 6. Verzonnen softwarepakketten in de code. 7. De server staat verzoeken toe vanaf elke website, inclusief inloggegevens (een te ruime CORS-instelling). 8. Opslag voor bestanden, zoals facturen of ID-bewijzen, is voor iedereen leesbaar.

9. Er is geen limiet op hoe vaak iemand een functie mag aanroepen. Bij een AI-functie loopt dan ook uw rekening bij de AI-leverancier op. 10. Beheer- en testpagina’s zoals /admin of /debug staan nog online. 11. Invoer van bezoekers gaat ongecontroleerd naar de database (injectie). 12. Het platform zelf zet onveilige standaardinstellingen, bijvoorbeeld een app die meteen openbaar is na publiceren.

Een scan vindt vooral de technische fouten: 1, 2, 7, 8 en 10. Fouten in de logica (3, 4 en 5) vindt alleen een mens. Iemand die de app gebruikt zoals een aanvaller dat zou doen.

Dit kunt u zelf controleren

Doe deze controles alleen op uw eigen app. 1. Maak twee testaccounts. Log in met account B en probeer gegevens van account A te openen. Verander bijvoorbeeld een nummer in de adresbalk. 2. Log uit en kijk wat u dan nog ziet. 3. Open in uw browser de paginabron of de ontwikkelaarstools en zoek op woorden als service_role, secret en sk_live. Vindt u een geheime sleutel, trek die dan direct in.

4. Kijk in Supabase bij elke tabel met klantgegevens of RLS aan staat. Kijk ook of de regel naar de ingelogde gebruiker kijkt (auth.uid()) in plaats van alles toe te staan. 5. Probeer /admin, /dashboard en /debug op uw eigen domein. 6. Zoek nieuwe softwarepakketten op voordat u ze installeert. 7. Geef een AI-agent nooit rechten op uw productiedatabase, en zorg voor een back-up die de agent niet kan wissen.

Veilige code vragen aan de AI helpt beperkt

Ja, het verkleint de kans op fouten. Supabase en Lovable hebben zelf voorbeeldprompts voor veilige databaseregels en sleutels. Maar een prompt bewijst niets. Lovable had een eigen beveiligingscontrole die alleen keek óf er een databaseregel bestond, niet of die regel echt werkte. Een regel die alles toestaat, zag er voor die controle hetzelfde uit als een goede.

In ons artikel over veilig prompten staan prompts die u direct kunt gebruiken. U leest er ook eerlijk wat ze niet oplossen.

Wanneer laat u uw AI-app testen?

Heeft u een website zonder inlog en zonder klantgegevens, dan geeft een Scan (vanaf € 295 excl. btw) een goed eerste beeld. Dat is een geautomatiseerde scan die wij met de hand nalopen, geen pentest. Hij vindt bijvoorbeeld zichtbare sleutels, open opslag en vergeten beheerpagina’s.

Loggen klanten in, of staan er persoonsgegevens in de database? Kies dan De Inbraaktest Totaal (vanaf € 4.950 excl. btw). Daarmee testen we met afgesproken testaccounts of gebruiker B bij gegevens van gebruiker A kan. Ook gebruikersrollen en API’s vallen binnen de afgesproken scope. Bij beide pentests is een hertest inbegrepen.

Test vóór de livegang, en opnieuw na grote wijzigingen. Een update van het platform kan een instelling terugzetten. Wij testen alleen na schriftelijke toestemming van de eigenaar van het systeem.