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.

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.