Waarom apps die met AI gebouwd zijn zo vaak lekken

In oktober 2025 publiceerde het beveiligingsbedrijf Escape een onderzoek naar ruim 5.600 apps die met AI-bouwplatforms waren gemaakt en openbaar online stonden. De onderzoekers keken alleen van buitenaf, zonder iets kapot te maken. Toch vonden ze meer dan 2.000 kwetsbaarheden, meer dan 400 sleutels en andere geheimen die voor het oprapen lagen, en 175 gevallen waarin persoonsgegevens te zien waren, waaronder medische gegevens en rekeningnummers. Ze noemen die aantallen zelf een ondergrens (de opzet van het onderzoek, in het Engels).

Bouwen met AI zonder zelf de code te lezen heet ook wel vibe coding. Het levert in korte tijd iets op dat werkt. Dat het ook veilig is, volgt daar niet uit. Wel zitten de meeste lekken op dezelfde paar plekken, en die kun je leren herkennen.

Wat de onderzoekers vonden

De fouten die Escape beschrijft, zijn niet ingewikkeld. Een groot deel zat in twee hoeken.

De eerste is een geheime sleutel in de code die de browser binnenkrijgt. Alles wat een site naar de browser stuurt, kan elke bezoeker lezen, ook de scripts die je op de pagina niet ziet. Staat daar een sleutel in waarmee je rechtstreeks in de database komt, dan heeft iedereen die sleutel. Volgens Escape waren zulke sleutels vaak eenvoudig uit die scripts te halen.

De tweede is een database zonder regels over wie wat mag zien. Veel van de onderzochte apps lieten de browser rechtstreeks met de database praten, met een sleutel die openbaar mag zijn. Dat is alleen veilig als er per tabel regels staan die bepalen welke rijen een bezoeker mag lezen of veranderen. De maker van een veelgebruikte databasedienst, Supabase, schrijft in de eigen documentatie dat een openbare tabel zonder die regels te lezen en te veranderen is door iedereen die er rechten op heeft. Via die openbare sleutel kan dat in de praktijk elke bezoeker zijn.

Dat de rest van zo’n app er verzorgd uitzag en precies deed wat de maker vroeg, maakte niets uit. Een lek als dit zie je niet bij gewoon gebruik.

Waarom het juist met AI zo vaak gebeurt

Een AI bouwt wat je vraagt. Vraag je om een pagina waar klanten hun offertes zien, dan krijg je een pagina die offertes laat zien. Dat een klant alleen zijn eigen offertes mag zien, is voor jou zo vanzelfsprekend dat je het niet zegt. Zeg je het niet, dan staat het nergens, en hangt het af van wat het model op dat moment bedenkt.

Daarbij is werken iets anders dan veilig zijn. Een sleutel in je script werkt prima, en een database zonder regels werkt ook. Het gaat pas mis als iemand anders er misbruik van maakt, en die meldt zich meestal niet.

Wat het verergert, is de snelheid. Een programmeur kijkt onderweg vanzelf naar wat hij bouwt. Wie met AI bouwt, leest de code meestal niet, en dat hoeft ook niet. Maar daardoor staat er soms binnen een uur iets online waar geen mens naar heeft gekeken.

Daar staat tegenover dat Claude de veilige manieren van werken goed kent. Vraag je er uitdrukkelijk om en laat je het daarna nakijken, dan gaat het meestal goed. De lijst die beveiligers als leidraad gebruiken, de OWASP Top 10, kent hij ook. OWASP is een internationale stichting voor veilige software. In de editie van 2025 staat op de eerste plek precies de fout van hierboven: gebruikers die bij gegevens of functies kunnen waar ze niet bij horen.

Wat je eigen server wel en niet tegenhoudt

Een goed ingerichte server houdt veel tegen. Op een server van retrAIt log je alleen in met een sleutel en worden beveiligingsupdates vanzelf geïnstalleerd. De webserver weigert bestanden waarvan de naam met een punt begint, zoals .env, en stuurt met elke pagina een paar beveiligingsregels mee aan de browser.

Dat is nodig, want bots gaan de hele dag alle adressen op internet langs, op zoek naar vergeten bestanden. In het logboek van mijn eigen server staan elke dag honderden verzoeken naar adressen als /.env en /.git/config. Welke bestanden je beter niet online kunt hebben, lees je in Wat staat er per ongeluk openbaar op je website.

Maar wat je zelf bouwt, valt erbuiten. Een pagina die de offertes van andere klanten laat zien, is voor de server een gewoon verzoek met een gewoon antwoord. Daar kan geen firewall iets aan doen. Dat gat zit in je eigen programma, en daar dicht je het ook.

Een voorbeeld. Jeroen is installateur en laat Claude een klantportaal bouwen waar klanten hun offerte bekijken op een adres als /offerte/215. Het werkt. Maar verandert een klant het nummer in 216, dan ziet hij de offerte van iemand anders, met naam, adres en prijs. Het portaal controleerde wel of er iemand was ingelogd, maar niet of deze offerte van hem was. Het is de fout die bovenaan de lijst van OWASP staat, en hij komt neer op één controle die ontbrak.

Wat je eraan doet

Je hoeft geen beveiliger te worden. Met een paar vaste gewoontes vang je het meeste af:

1. Noem veiligheid in je opdracht. Schrijf erbij wie wat mag zien, en dat geheime sleutels alleen op de server staan. Hoe je zo’n opdracht opbouwt, staat in Van idee naar specificatie.
2. Houd sleutels uit alles wat de browser krijgt. Ze horen in een bestand op je server dat niet online komt en niet in git staat, zoals beschreven in Wachtwoorden en API-sleutels in je code.
3. Test als een buitenstaander. Maak een tweede account aan, log daarmee in en probeer bij de gegevens van het eerste te komen, bijvoorbeeld door een nummer in het adres te veranderen.
4. Laat Claude een veiligheidsronde doen, in een nieuwe sessie en met de opdracht eerst alleen te onderzoeken. Loop de bevindingen daarna samen na en beslis zelf wat er verandert.
5. Weet vooraf wat je doet als het toch misgaat: waar je een sleutel intrekt, en wat je moet doen als er gegevens van mensen zijn uitgelekt. Dat staat in Een datalek op je eigen site.

Geen van deze stappen garandeert dat er nooit iets misgaat. Samen maken ze wel het verschil tussen een app waar iedereen met een beetje kennis in kan, en een app waar een aanvaller echt moeite voor moet doen.

Neem vandaag het project dat je met AI hebt gebouwd en vraag Claude, zonder iets te veranderen, er een kaart van te maken: welke pagina’s en bestanden online staan, waar bezoekers iets kunnen invullen, waar gegevens worden bewaard en wie wat mag zien. Lees die kaart als een buitenstaander. De plek waarvan je denkt dat een ander er niet bij kan, is de plek die je als eerste test. Wil je dit stap voor stap doen, dan staat er in het online programma een leerlijn over veilig bouwen.