Laat uw met AI gebouwde app testen

Waarom AI-code vaak lekt

Een AI-tool bouwt wat u vraagt en wil het zo snel mogelijk werkend hebben. Blokkeert een toegangsregel de preview? Dan is de snelste oplossing de regel uitzetten. Heeft de app een sleutel nodig, dan komt die soms gewoon in code die elke bezoeker kan lezen. De app werkt, dus niemand kijkt verder. Dat is geen reden om niet met AI te bouwen. Het is wel een reden om te testen voordat er klantgegevens in staan.

Dat het vaak misgaat, is gemeten. Veracode testte in 2025 meer dan 100 taalmodellen. In 45% van de gegenereerde code zat een kwetsbaarheid uit de OWASP Top 10. Nieuwere en grotere modellen deden het niet beter.

Bij Lovable bleek in maart 2025 dat 170 van 1.645 onderzochte apps gegevens prijsgaven zonder inlog. Het ging om namen, e-mailadressen, telefoonnummers en API-sleutels. De oorzaak waren ontbrekende toegangsregels (Row Level Security) in de Supabase-database. Het lek kreeg nummer CVE-2025-48757, met ernstscore 9,3 van 10.

In mei 2026 beschreef WIRED een onderzoek van RedAccess naar ongeveer 380.000 openbare apps. Die draaiden op Lovable, Replit, Base44 en Netlify. Zo’n 5.000 apps hadden geen enkele toegangscontrole. Ongeveer 2.000 daarvan lieten gevoelige gegevens zien, zoals roosters met patiëntgegevens. De platforms reageerden dat de instellingen de verantwoordelijkheid van de gebruiker zijn.

Ook de onderdelen die de AI zelf kiest, verdienen aandacht. Onderzoekers lieten 16 taalmodellen 576.000 keer code schrijven: 19,7% van de aangeraden softwarepakketten bestond niet. Aanvallers registreren zulke verzonnen namen met schadelijke code erin (USENIX Security 2025).

Ook testen als uw platform zelf scant

Platforms als Lovable bieden zelf een beveiligingsscan. Dat is een goed begin. Maar zo’n scan kijkt vooral of er een regel bestaat, niet of hij werkt. In 2025 zag een regel die iedereen toelaat er voor de scan van Lovable hetzelfde uit als een goede. Lovable schrijft in de eigen documentatie dat de code in de browser altijd openbaar is. Beveiliging hoort volgens Lovable in de database en op de server.

Kan klant A echt niet bij de gegevens van klant B? Dat ziet u pas als iemand het met twee accounts probeert. Dat doen wij bij een pentest.

AI-functies in uw app: chatbot of taalmodel

Heeft uw app zelf een chatbot of een koppeling met een taalmodel? Dan komen er andere risico’s bij. Die staan in de OWASP Top 10 for LLM Applications (2025). Een voorbeeld is prompt injection: een gebruiker stuurt de chatbot met een slimme vraag een andere kant op. Ook kan de chatbot zijn interne instructies lekken of te veel rechten in uw systemen krijgen. Of hij draait onbeperkt op uw kosten. Dit testen we in De Inbraaktest Totaal, met toegang tot hoe de functie is opgebouwd.

Daarnaast vergeten veel ondernemers twee regels. Sinds 2 augustus 2026 moet een chatbot laten weten dat de gebruiker met AI praat (AI Act, artikel 50). Typt een klant persoonsgegevens in de chat? Dan heeft u een verwerkersovereenkomst met de leverancier nodig (AVG, artikel 28). Dat is geen technische test en geen juridisch advies. We noemen het wel in het rapport als we het tegenkomen.

Wat u vooraf regelt

Een testomgeving. Het liefst een kopie van uw app met eigen database en alleen testgegevens. Dan merken uw echte klanten er niets van. Bij Supabase kan dat bijvoorbeeld met een apart project. Zet betalingen op die kopie in testmodus.

Toegang om mee te kijken. Als uw platform het toelaat, is dat een account met alleen leesrechten op uw Supabase- of Firebase-project. Zo lezen we de toegangsregels zelf in plaats van ze te raden. Kan dat niet, dan is een export van de regels ook goed. Voor de Inbraaktest Totaal maakt u twee testaccounts per rol aan. Daarmee kijken we of de ene gebruiker bij de gegevens van de andere kan.

En een lijstje. Met welke AI-tool en welke backend is de app gebouwd? Welke betaal- en AI-diensten zijn gekoppeld? En waar draait hij, bijvoorbeeld op Vercel of Netlify? Wachtwoorden spreken we nooit per gewone e-mail af.

Testen binnen de regels van uw platform

Uw app draait vaak op het platform van een ander. Denk aan Lovable, Supabase, Firebase, Vercel of Netlify. Wij testen alleen uw eigen project en houden ons aan de testregels van dat platform. Het platform zelf testen we niet en we doen geen belastingtests. Vinden we toch iets dat bij het platform ligt, dan melden we dat via hun eigen meldpunt.

Een test is een momentopname. Een update van het platform of een nieuwe ronde met uw AI-tool kan een instelling terugzetten. Bouwt u veel bij, dan is een abonnement handig: elke maand een check, vanaf € 79 per maand.

Bronnen

• Veracode: GenAI Code Security Report 2025
• NVD: CVE-2025-48757
• Matt Palmer: statement over CVE-2025-48757
• WIRED: Thousands of vibe-coded apps expose data (mei 2026)
• USENIX Security 2025: package hallucinations
• Superblocks: Lovable vulnerability explained
• Lovable Docs: Security best practices
• Supabase Docs: Row Level Security
• OWASP Top 10 for LLM Applications 2025
• EU AI Act: tijdlijn

Verder lezen

• Gratis: checklist + prompts: Twaalf punten die u zelf naloopt en tien veilige prompts.
• Veilig bouwen met AI: Wat vibe coding is en waar het misgaat.
• Supabase RLS uitgelegd: Waarom gebruikers elkaars gegevens kunnen zien.
• API-sleutels in uw app: Welke sleutel openbaar mag en welke niet.
• Prompt injection uitgelegd: Hoe een chatbot de verkeerde kant op gaat.
• Chatbot, AVG en AI Act: Wat u regelt als uw app een chatbot heeft.