Van prototype naar productie: de go-live check voor apps gebouwd met AI

Van prototype naar productie: de go-live check voor apps gebouwd met AI

Een app gebouwd met Lovable, Bolt, Cursor of Replit kan in een demo perfect werken en toch elke ingelogde gebruiker de data van alle anderen laten zien. Doe deze zeven controles voor er echte gebruikers en echte data op komen. Een deel kun je zelf. Voor de rest heb je een webapplicatie pentest nodig, door iemand die de app bewust probeert te breken.

TL;DR

• AI-codeertools bouwen snel functies, maar bepalen zelden wie welke data mag zien.
• Zeven controles dekken de meeste risico's bij lancering: databaseregels, geheimen, autorisatie tussen gebruikers, login en sessies, betalingen, browserbescherming, en opslag en hosting.
• De configuratiecontroles kun je zelf in een namiddag nakijken.
• Autorisatiefouten en gekoppelde aanvallen vragen een menselijke tester.
• Een go-live pentest geeft je een go of no-go voor de lancering, met de hertest inbegrepen.

Waarom apps gebouwd met AI met gaten in productie belanden

AI-codeertools mikken op een functie die werkt. Beveiliging zit zelden in de prompt, dus zelden in het resultaat. Toen Escape eind 2025 meer dan 5.600 publiek draaiende apps scande, gebouwd op platformen zoals Lovable, Bolt.new en Base44, vond het meer dan 2.000 kwetsbaarheden, meer dan 400 blootgestelde geheimen en 175 gevallen van blootgestelde persoonsgegevens (onderzoek van Escape). De Vibe Security Radar van Georgia Tech telde 6 gepubliceerde kwetsbaarheden afkomstig van AI-code in januari 2026, 15 in februari en 35 in maart (Infosecurity Magazine).

Eerder legden we uit wat er typisch misgaat in een vibe-coded app. Dit artikel is het praktische vervolg: wat je controleert voor je op de lanceerknop drukt.

De zeven controles voor je live gaat

1. Databaseregels en row-level security

Apps op Supabase of Firebase praten rechtstreeks vanuit de browser met de database. Dat is alleen veilig als de database zelf bepaalt wie elke rij mag lezen en wijzigen. Controleer of row-level security aan staat voor elke tabel en of elke regel de toegang beperkt tot de eigen records van de gebruiker. Een tabel zonder die beveiliging, of met een regel die elke ingelogde gebruiker toelaat, staat open voor iedereen met een account.

2. Geheimen in de frontend en de repository

Open je app in de browser, bekijk de broncode en zoek in de JavaScript-bestanden naar woorden als key, secret en token. Een publieke sleutel die voor de browser bedoeld is, is geen probleem. Een servicesleutel, een betaalgeheim of een API-sleutel voor een AI-dienst wel. Kijk ook in de geschiedenis van je repository, want een sleutel die je later verwijderde, staat nog in oude commits. Vervang elke sleutel die je vindt.

3. Autorisatie tussen gebruikers

Log in als twee testgebruikers. Kopieer een link of een ID van gebruiker A en open die als gebruiker B. Ziet B de factuur, het profiel of het bestand van A, dan controleert de app wel dat iemand ingelogd is, maar niet of de data van die persoon is. Geautomatiseerde scanners vinden deze fout, vaak IDOR genoemd, moeilijk. In de test van Tenzai, waarin vijf AI-codeeragents elk dezelfde drie apps bouwden, hoorde onjuiste API-autorisatie bij de meest voorkomende van 69 bevindingen (SecurityWeek).

4. Login, wachtwoordreset en sessies

Test de stappen rond de login, niet alleen het loginformulier. Werkt een resetlink twee keer? Stopt een sessie als iemand uitlogt? Komt een gewone gebruiker op een beheerpagina door het adres in te typen? Gegenereerde code verbergt vaak een knop in de interface, maar laat de functie erachter open.

5. Betalingen en webhooks

Neemt je app betalingen aan, controleer dan dat de prijs en de betaalstatus van de betaalprovider komen en niet van de browser. Een webhook die een betaling bevestigt, moet de handtekening van de provider controleren. Anders kan iedereen je app een vals bericht sturen dat er betaald is.

6. Browserbescherming en serververzoeken

Controleer of de app de basis-securityheaders zet en zijn formulieren beschermt tegen verzoeken vanaf andere sites. Haalt de app een URL op namens de gebruiker, voor een afbeeldingsvoorbeeld of een import, test dan of je die naar interne adressen kunt laten wijzen. Die fout, server-side request forgery, dook op in de output van alle vijf agents in de test van Tenzai.

7. Opslagbuckets, afhankelijkheden en hosting

Geüploade bestanden komen vaak terecht in een opslagbucket die standaard publiek is. Controleer wie de bestanden kan oplijsten en downloaden. Laat een controle lopen op de pakketten die de AI toevoegde en verwijder wat je niet gebruikt. Kijk daarna de hostinginstellingen na: debugmodus uit, testaccounts weg en omgevingsvariabelen alleen waar ze horen.

Wat je zelf kunt nakijken en wat een pentest vraagt

Controles 1, 2 en 7 gaan vooral over configuratie. Een ontwikkelaar of een technische oprichter kijkt ze in een namiddag na met de eigen beveiligingstools van het platform. Controles 3, 4, 5 en 6 hangen af van hoe de app zich gedraagt bij misbruik. Daar voegt een menselijke tester het meest toe: iemand die als verschillende gebruikers inlogt, verzoeken bewust aanpast en kleine zwaktes koppelt tot een echt aanvalspad.

Sectricity biedt dit aan als de Go-Live Pentest, een webapplicatie pentest voor apps gebouwd met AI, uitgevoerd voor de lancering. Je krijgt een duidelijk go of no-go, bevindingen in gewone taal, per bevinding een herstelinstructie die je in je AI-codeertool kunt plakken, en een hertest zodra je de bevindingen hebt opgelost.

Na de lancering: test elke release die datatoegang verandert

Een app gebouwd met AI staat zelden stil. Elke nieuwe functie kan veranderen wie welke data ziet. Met RedSOC vraag je een pentest aan wanneer je iets nieuws uitbrengt, zodat de volgende release dezelfde controle krijgt als de eerste.

Veelgestelde vragen

Is een app gebouwd met Lovable of Bolt veilig om te lanceren?

Dat kan, maar het platform beslist dat niet voor jou. Het genereert de code en de hosting. Databaseregels, toegang tussen gebruikers en de omgang met geheimen blijven jouw verantwoordelijkheid. Doe de zeven controles uit dit artikel voor de lancering, en laat de app testen als ze persoonsgegevens of betalingen verwerkt.

Kan ik de ingebouwde beveiligingsscan van het platform gebruiken in plaats van een pentest?

Gebruik hem zeker, want hij vindt configuratiefouten snel. Hij logt niet in als twee gebruikers om elkaars data te proberen lezen, en hij koppelt geen kleine fouten tot een aanvalspad. Een scan en een pentest beantwoorden andere vragen.

Wat is een Go-Live Pentest?

Het is de webapplicatie pentest van Sectricity voor apps gebouwd met AI-codeertools, uitgevoerd voor de lancering. De test richt zich op datatoegang, geheimen, login en betaalflows, en eindigt met een go of no-go, een herstelinstructie per bevinding en een inbegrepen hertest.

Hebben jullie toegang tot mijn code nodig?

Nee, we kunnen de draaiende app op zich testen. Toegang tot de repository en de database-instellingen maakt de test sneller en vollediger, omdat we de regels achter het gedrag van de app zien.

Wat doe ik na de lancering?

Test opnieuw wanneer een release verandert wie welke data ziet, bijvoorbeeld nieuwe rollen, deelfuncties of integraties. Met RedSOC vraag je die pentest aan wanneer je hem nodig hebt.

Gerelateerde diensten en bronnen

Sectricity test applicaties, of ze nu met AI gebouwd zijn of niet. Begin bij onze webapplicatie pentest, waar de Go-Live Pentest voor apps gebouwd met AI onder valt. Zit er een AI-assistent of agent in je app, dan dekt onze AI- en agent security test prompt injection en agentrechten af. Teams die vaak releasen gebruiken RedSOC voor pentesting op afroep, en bij elke pentest hoort een hertest van je fixes. Lees voor achtergrond wat er typisch misgaat in een vibe-coded app en wat je AI-agent in productie kan bereiken.