Veiligheid van AI-gegenereerde code: 8 controles die je niet mag overslaan

AI-gegenereerde code is niet automatisch veilig omdat de applicatie werkt of een beveiligingsscan groen is. Controleer vóór gebruik met echte klanten minimaal toegangsrechten, invoer en uitvoer, geheime sleutels, afhankelijkheden, persoonsgegevens, bedrijfsregels, eventuele AI-koppelingen en het beheer van de productieomgeving. Laat iedere controle een aantoonbaar resultaat opleveren: een test, een gecontroleerde instelling of een geslaagde herstelproef.

Met vibe coding kun je snel een eerste website of applicatie maken. Die snelheid is waardevol, maar zegt weinig over de vraag of klant A de bestanden van klant B kan zien of een foutieve aanvraag een betaling veroorzaakt. Deze checklist vertaalt softwarebeveiliging naar acht concrete controles voor MKB-ondernemers en hun bouwpartner. Het is een praktische basis, geen volledige audit, certificering of garantie dat alle kwetsbaarheden zijn gevonden.

De acht beveiligingscontroles in één overzicht

1. Toegangsrechten: kan iedere gebruiker alleen zijn eigen gegevens en toegestane functies bereiken?
2. Invoer en uitvoer: wordt onbetrouwbare informatie gecontroleerd en veilig verwerkt?
3. Geheime sleutels: blijven private API-sleutels en beheertoegang buiten de browser en repository?
4. Afhankelijkheden: zijn packages, versies en updates gecontroleerd?
5. Persoonsgegevens: verzamel, deel en bewaar je alleen wat nodig is?
6. Bedrijfsregels: voorkomt het systeem misbruik van prijzen, aanvragen en acties?
7. AI-koppelingen: krijgt een model niet méér gegevens of bevoegdheden dan noodzakelijk?
8. Productiebeheer: kun je fouten signaleren, toegang intrekken en gegevens herstellen?

Laat de bouwer per onderdeel vastleggen wat is getest, met welke testaccounts, wat de uitkomst was en wie een tekortkoming oplost. Gebruik voor een uitgebreide opdracht een passend verificatiekader, zoals OWASP ASVS, in plaats van alleen deze korte lijst.

Waarom een werkende AI-app nog geen veilige app is

Een demonstratie toont meestal de gewenste route: aanmelden, een formulier invullen en het resultaat zien. Beveiliging gaat ook over routes die je níét wilt toestaan. Denk aan een bezoeker zonder account, een medewerker met beperkte rechten of een herhaalde aanvraag die de gebruikelijke volgorde overslaat.

AI kan code schrijven die er overtuigend uitziet, maar verkeerde aannames bevat over identiteit, gegevensbezit of de plek waar een controle moet plaatsvinden. Dat probleem is niet exclusief voor AI: ook handgeschreven software kan onveilig zijn. De bruikbare vraag is daarom niet ‘Heeft AI dit gemaakt?’, maar ‘Zijn de relevante risico’s gecontroleerd en aantoonbaar afgedekt?’

Lees ook waarom vibe-coded apps bij de overgang naar productie stranden. Dit artikel zoomt specifiek in op beveiliging; het eerdere artikel behandelt daarnaast onderhoud, schaalbaarheid en overdracht.

1. Controleer toegangsrechten met verschillende gebruikers

Inloggen bewijst wie iemand is; autorisatie bepaalt wat die persoon mag doen. Een verborgen beheerdersknop of een afgeschermd scherm is niet genoeg. De server en gegevensopslag moeten een niet-toegestane aanvraag ook weigeren.

Gebruik in een eigen testomgeving minimaal twee gewone testaccounts met verschillende gegevens en, als die bestaat, een beheerder. Controleer of ieder account alleen de eigen dossiers, uploads en functies bereikt. Test dezelfde handelingen zonder sessie en na uitloggen. Beoordeel ook directe toegang tot bestanden en exports, niet alleen wat de schermen laten zien.

• Laat controleren dat eigenaar en rol worden afgeleid van de geverifieerde gebruiker, niet van vrij wijzigbare invoer.
• Beperk rechten op gegevensniveau; een klant mag niet alle rijen lezen omdat het scherm er slechts enkele toont.
• Controleer toegang bij lezen, toevoegen, wijzigen én verwijderen.

Bewijs voor oplevering: geslaagde tests voor toegestane acties en geweigerde acties tussen de testaccounts. Test alleen systemen waarvoor je toestemming hebt en gebruik geen echte klantdossiers als oefenmateriaal.

2. Controleer invoer, uploads en veilige uitvoer

Alles wat van een gebruiker of externe dienst komt, moet als onbetrouwbaar worden behandeld. Dat geldt voor formulierwaarden, bestandsnamen, ontvangen HTML en antwoorden van een AI-model. Een verplicht veld in de browser is handig, maar geen vervanging voor controle aan de serverkant.

Laat de ontwikkelaar controleren of type, lengte en toegestane waarden worden afgedwongen. Databasevragen horen veilig met parameters te worden uitgevoerd; onbetrouwbare inhoud mag niet zomaar als actieve HTML verschijnen. Bestandsuploads vragen afzonderlijke controles op formaat, omvang, opslaglocatie en toegang. Alleen de extensie van een bestand bekijken is onvoldoende.

Praktijktest: probeer in de testomgeving lege, te lange en ongeldige invoer en controleer of het systeem die begrijpelijk afwijst zonder gegevens te veranderen. Laat gevaarlijke invoer en uploadscenario’s door een deskundige testen. Controleer dat foutmeldingen geen geheime instellingen of klantgegevens tonen.

Bewijs voor oplevering: tests op servervalidatie en veilige weergave, plus gedocumenteerde uploadregels passend bij de toepassing.

3. Houd private sleutels en beheertoegang geheim

Een private API-sleutel in browsercode is geen geheim, ook niet als de tekst is versleuteld ogend, geminimaliseerd of verborgen in een instelling die naar de browser wordt meegestuurd. Publieke sleutels die uitdrukkelijk voor browsergebruik zijn bedoeld, vormen een andere categorie; daar horen de juiste toegangsbeperkingen bij.

• Bewaar private sleutels aan de serverkant in een geschikte geheimenvoorziening.
• Gebruik afzonderlijke toegang voor testen en productie, met zo beperkt mogelijke bevoegdheden.
• Controleer repository, geschiedenis, browserbestanden en logs op onbedoelde geheimen.
• Trek een gelekte sleutel in en vervang die; alleen de zichtbare tekst verwijderen maakt oude toegang niet onbruikbaar.

Bewijs voor oplevering: een beoordeeld overzicht van geheime instellingen en eigenaarschap, zonder de geheime waarden in het opleverdocument te zetten. Spreek af wie sleutels vernieuwt en wie toegang kan intrekken.

4. Controleer packages en kwetsbare afhankelijkheden

AI kan bestaande bibliotheken toevoegen om snel een functie te bouwen. Controleer of het pakket echt bestaat, uit een betrouwbare bron komt en nodig is. Beoordeel de concrete versie, bekende kwetsbaarheden en onderhoudsstatus; een bekende pakketnaam alleen is geen veiligheidsbewijs.

Gebruik een vastgelegd dependency-overzicht en een lockfile voor reproduceerbare installatie. Een automatische dependency-scan helpt bij het vinden van bekende problemen. Beoordeel vervolgens of en hoe de betreffende kwetsbaarheid jouw toepassing raakt, en test updates voordat je ze naar productie brengt. Een scan kan onbekende kwetsbaarheden of fouten in eigen bedrijfslogica missen.

Bewijs voor oplevering: een recente scan, beoordeling van relevante bevindingen en afspraken over updates. Licenties zijn een aparte controle; daarvoor lees je wie de code bezit en welke rechten op onderdelen gelden.

5. Beperk persoonsgegevens en controleer de gegevensstromen

Breng in kaart welke gegevens je verzamelt, waar ze worden opgeslagen en welke externe diensten ze ontvangen. Gebruik bij bouwen en testen bij voorkeur fictieve gegevens. Een kopie van productiegegevens bevat dezelfde privacyrisico’s als de oorspronkelijke omgeving.

Bij persoonsgegevens moet je naast technische beveiliging onder meer doel, rechtsgrond, bewaartermijn en afspraken met verwerkers beoordelen. Stuur klantinformatie niet automatisch naar een AI-provider omdat een koppeling beschikbaar is. Controleer of die verwerking nodig is en welke voorwaarden, locaties en bewaarmogelijkheden gelden.

• Verzamel alleen gegevens die bij het afgesproken doel passen.
• Beperk toegang tot exports, uploads, logs en testomgevingen.
• Test verwijdering en leg vast hoe bewaartermijnen zich verhouden tot back-ups.
• Controleer dat foutmeldingen en analyses geen onnodige persoonsgegevens bevatten.

Bewijs voor oplevering: een gegevensstroomoverzicht, passende afspraken en geteste toegang en verwijdering. Deze technische checklist verklaart je applicatie niet automatisch AVG-conform.

6. Test bedrijfsregels en herhaalde acties

Een aanvraag kan technisch geldig zijn en toch zakelijk verkeerd. Denk aan een korting die door de gebruiker wordt aangepast, een dubbele boeking of een terugbetaling die twee keer wordt uitgevoerd. Zulke fouten blijven vaak buiten een eenvoudige code- of dependency-scan.

Laat prijzen, rechten, voorraad en statusovergangen controleren op een vertrouwde plek aan de serverkant. Test wat er gebeurt wanneer iemand een actie opnieuw uitvoert, stappen overslaat of twee verzoeken tegelijk verstuurt. Voor financiële of andere kritieke acties kan een mechanisme nodig zijn dat dubbele verwerking voorkomt.

Beperk bovendien onnodig hoge aantallen aanvragen. Kies limieten en misbruikdetectie op basis van het bedrijfsproces; een algemene limiet die nergens is getest kan normale gebruikers blokkeren en toch misbruik toelaten.

Bewijs voor oplevering: tests met concrete bedrijfsvoorbeelden en verwachte uitkomsten. Laat een medewerker die het proces kent meebeoordelen, naast de ontwikkelaar.

7. Beperk de bevoegdheden van eventuele AI-koppelingen

Een AI-gebouwde applicatie hoeft zelf geen AI-model te gebruiken. Deze controle is alleen van toepassing als jouw app een model, agent of AI-dienst aanroept. Het risico van prompt injection betreft dan onder meer onbetrouwbare tekst die het model probeert aan te zetten tot ongewenste handelingen.

Een systeemprompt als ‘deel geen privégegevens’ is geen autorisatiecontrole. Laat de applicatie zelf bepalen welke gegevens de gebruiker mag ophalen en welke acties zijn toegestaan. Geef een model niet standaard toegang tot alle klantdossiers of brede beheerdersrechten.

• Behandel documenten, webinhoud en modeloutput als onbetrouwbare invoer.
• Valideer AI-resultaten voordat je ze opslaat, toont of gebruikt voor een actie.
• Beperk beschikbare acties en controleer parameters en rechten buiten het model.
• Vraag waar passend menselijke bevestiging voor risicovolle handelingen, zoals betalingen of definitieve verzending.
• Beperk gebruik en kosten en zorg dat een fout van de AI-dienst de kernfunctie niet onveilig maakt.

Bewijs voor oplevering: tests waarin ongewenste instructies geen extra toegang of bevoegdheden opleveren, plus veilige afhandeling van ongeldige output en dienstuitval.

8. Controleer productie, logging en herstel

Een veilige testversie zegt niet genoeg over de uiteindelijke productieomgeving. Controleer domein en HTTPS, sessie-instellingen, beheertoegang, opslagrechten en de werkelijke configuratie van diensten. Een publiek bereikbare testpagina of ruimere productiepolicy kan eerdere controles tenietdoen.

Leg vast welke fouten en verdachte acties worden gelogd, wie meldingen ontvangt en hoe daarop wordt gereageerd. Logs mogen geen verzameling wachtwoorden, toegangstokens of onnodige klantdata worden. Maak back-ups, maar test ook herstel van database, bestanden en benodigde instellingen; het bestaan van een back-up is geen bewijs van herstelbaarheid.

Bewijs voor oplevering: een gecontroleerde productieconfiguratie, werkende meldingen en een geslaagde herstelproef in een afgeschermde omgeving. Spreek af wie incidenten behandelt en hoe je toegang van een vertrokken medewerker of bureau intrekt.

Fictief voorbeeld: een offertetool met een verborgen toegangsprobleem

Dit voorbeeld is verzonnen en geen klantcase. Een groothandel bouwt met AI een offertetool. Medewerkers kunnen inloggen en offertes bekijken. In de demonstratie ziet ieder testaccount alleen de eigen offertes, omdat het scherm ze filtert.

Bij de autorisatiecontrole blijkt dat de gegevenslaag ruimere leesrechten heeft dan bedoeld. De ontwikkelaar beperkt de toegang op basis van de geverifieerde gebruiker en voegt tests tussen twee accounts toe. Daarnaast wordt een private mailsleutel uit de browser verwijderd en ingetrokken, en wordt getest dat dezelfde aanvraag geen dubbele verzending veroorzaakt.

De tool gaat pas naar productie nadat de bevindingen opnieuw zijn getest. De les is niet dat AI-bouw per definitie onveilig is, maar dat het gewenste schermgedrag geen bewijs vormt voor veilige gegevensverwerking.

Wanneer laat je een specialist meekijken?

Schakel aanvullende expertise in bij persoonsgegevens met hoge risico’s, betalingen, omvangrijke koppelingen, meerdere klantorganisaties of AI-agents met actiebevoegdheden. Spreek scope en diepgang af: een code-review, configuratiecontrole en penetratietest zijn verschillende werkzaamheden. Geen daarvan is een permanente garantie.

Stel een bevinding met ongeoorloofde gegevenstoegang, een gelekte private sleutel of een onbetrouwbare financiële actie niet uit tot ‘na de lancering’. Laat het risico beoordelen, herstel het probleem en controleer het resultaat opnieuw. Gebruik de acceptatiechecklist voor het MKB om ook eigenaarschap en onderhoud mee te nemen.

SEO en GEO vervangen geen beveiliging

Een snelle, goed vindbare website kan nog steeds onveilig zijn. Publiceer geen claims als ‘100% veilig’ of ‘AVG-proof’ op basis van alleen een scan. Beschrijf liever welke controles zijn uitgevoerd en op welk moment. Dat levert controleerbare informatie op voor bezoekers; het garandeert geen ranking of vermelding door AI-systemen.

Wil je een website of applicatie bouwen met AI? Bespreek met ons AI marketing bureau niet alleen de eerste versie, maar ook verificatie, beheer en veilige overdracht.

Veelgestelde vragen over veiligheid van AI-gegenereerde code

Is AI-gegenereerde code onveiliger dan handgeschreven code?

Dat kun je niet voor iedere applicatie algemeen vaststellen. Beide kunnen kwetsbaarheden bevatten. Beoordeel de concrete architectuur, code, instellingen en tests, niet alleen de manier waarop de code is gemaakt.

Is een groene beveiligingsscan genoeg om live te gaan?

Nee. Een scan kan nuttige bevindingen opleveren, maar mist mogelijk bedrijfslogica, verkeerde rechten en onbekende kwetsbaarheden. Combineer scans met praktijktests, review en controle van de productieconfiguratie.

Waarom is een login niet voldoende voor een klantportaal?

Een login stelt identiteit vast. Je moet daarnaast afdwingen welke gegevens en functies die gebruiker mag bereiken. Test dat klanten ook buiten de zichtbare schermen geen gegevens van anderen kunnen lezen of wijzigen.

Moet een publieke API-sleutel altijd verborgen blijven?

Niet iedere sleutel is geheim. Sommige sleutels zijn bedoeld voor browsergebruik, met bijbehorende beperkingen. Private sleutels en beheersleutels horen niet in browsercode; beoordeel het type en de bevoegdheden van iedere sleutel.

Geldt prompt injection voor iedere met AI gebouwde website?

Nee. Deze controle is relevant wanneer de applicatie zelf een model of agent gebruikt en onbetrouwbare inhoud verwerkt. AI gebruiken tijdens de bouw betekent niet automatisch dat de uiteindelijke website zo’n koppeling heeft.

Kan ik beveiligingstests uitvoeren met echte klantgegevens?

Gebruik bij voorkeur fictieve testgegevens in een afgeschermde omgeving. Als echte persoonsgegevens noodzakelijk zijn, moet die verwerking passend worden ingericht en beveiligd. Test alleen systemen waarvoor je toestemming hebt.

Hoe vaak moet ik de acht controles herhalen?

Herhaal relevante controles na wijzigingen in rechten, koppelingen, gegevensverwerking en productieconfiguratie. Spreek daarnaast periodieke controles af op basis van risico en onderhoud; één oplevercontrole dekt toekomstige veranderingen niet.

Bronnen en verantwoording

Geraadpleegd op 10 november 2026. De acht controles zijn een praktische selectie, geen verklaring van volledige naleving van OWASP ASVS. De juiste testdiepgang hangt af van de toepassing, gegevens en bedrijfsrisico’s.

• OWASP Application Security Verification Standard (ASVS), versie 5.0.0 — verificatie-eisen voor onder meer autorisatie, invoer, secrets, afhankelijkheden en gegevensbescherming.
• OWASP LLM01:2025 — Prompt Injection — directe en indirecte manipulatie van toepassingen die LLM’s gebruiken.
• NIST SP 800-218 — Secure Software Development Framework, versie 1.1 — veilige ontwikkel- en onderhoudspraktijken.
• Lovable Docs — Security overview — mogelijkheden en beperkingen van beveiligingsscans.
• Lovable Docs — Security best practices — vertrouwde controles, gegevensrechten en server-side bescherming van geheimen.