Wat een vibe coding security checklist mist (en hoe je die aanvult)

Je team leverde werkende code op. Niemand controleerde waar die bij mag

Stel je voor: iemand in je team bouwde met een AI-agent in een middag een interne tool. Hij werkt. Hij hangt aan je CRM, misschien aan je ERP, misschien aan een Slack-kanaal. Iedereen blij — tot iemand zachtjes vraagt: "wacht even, bij welke data kan dit ding eigenlijk?"

Dat is meestal het moment waarop het misgaat. Vibe coding — software bouwen door te beschrijven wat je wilt en een AI-model de implementatie laten schrijven — is echt snel. Van discovery naar een werkende tool in één tot drie weken is realistisch. Maar snelheid verbergt beslissingen. De AI kiest een autorisatiepatroon, bepaalt waar een sleutel wordt opgeslagen, bepaalt hoeveel data uit een API komt, en niets daarvan is zichtbaar in de demo. Het wordt pas zichtbaar later, meestal op een manier die je niet zelf gekozen had.

Generieke security-checklists voor vibe coding dekken de basis: HTTPS, XSS-sanitatie, CSRF-tokens, parameterized queries ( de checklist van Replit is een goed startpunt). Community-lijsten zoals de vibe-security checklist op GitHub gaan verder met implementatievoorbeelden. Die zijn het lezen waard. Maar als Head of Development die verantwoordelijk is voor wat er daadwerkelijk productie haalt, is dat de makkelijke 80%. Wat in de praktijk echt stukgaat is smaller en specifieker — en dat behandelen de meeste checklists als voetnoot.

Waarom de standaardchecklist niet genoeg is voor een Head of Development

Standaardchecklists zijn geschreven voor degene die de AI aanstuurt. Ze beantwoorden "heb ik deze input gesanitized" en "gebruik ik HTTPS". Nuttig, maar ze gaan ervan uit dat je één bestand tegelijk beoordeelt.

Als degene die verantwoordelijk is voor wat er live gaat, loop je een ander risico. Je controleert geen losse functie — je controleert of een AI-ondersteunde bouw veilige architectuurkeuzes maakt over een heel systeem: als wie het mag authenticeren, wat het waar opslaat, wat het mag ophalen, en of dat over een half jaar nog te begrijpen is als iemand anders het onderhoudt.

In onze eigen reviews van AI-gegenereerde code bij MKB-klanten komen vier problemen vaker voor dan al het andere op de standaardlijsten bij elkaar: te brede rechten, secrets in de verkeerde laag, ontbrekende inputvalidatie, en integraties die veel meer data ophalen dan de functie nodig heeft. De redenering daarachter staat in Vibe Coding: de verborgen beveiligingsrisico's van AI-gegenereerde code . Hieronder staat de checklist die we echt aflopen, opgebouwd rond die vier.

1. Rechten: wat mag deze code eigenlijk?

AI-modellen kiezen de weg van de minste weerstand — wat in code vaak de weg van de meeste toegang is, omdat dat simpeler te schrijven is en het meteen 'werkt' bij het testen.

Let op:

• Service-accounts en API-sleutels met beheerdersrechten waar alleen-lezen of een smalle scope volstaat.
• Autorisatiechecks die ontbreken bij het endpoint, niet alleen in de interface. AI-gegenereerde frontends verbergen een knop vaak keurig, maar blokkeren het onderliggende verzoek niet. Controleer rechten server-side vóórdat een actie wordt uitgevoerd, niet alleen voordat je de optie toont.
• Gedeelde of standaard-inloggegevens die uit een tutorial of template zijn overgenomen.
• Geen toets op minimale rechten — heeft iemand echt gevraagd of deze workflow schrijfrechten op het hele CRM nodig heeft, of alleen op één objecttype?

Dit is de categorie die een werkende demo verandert in een risico zodra er echte klantdata doorheen stroomt. Het is ook de categorie die het vaakst nog fout staat nadat een mens er 'even naar gekeken' heeft — want te brede rechten geven geen foutmelding. Ze zitten er gewoon, stilletjes, tot er iets misgaat.

2. Secrets: waar staat de sleutel echt?

Generieke checklists zeggen "gebruik een secrets-manager". Klopt, maar de echte faalmodus bij AI-gegenereerde code is specifieker: het model zet de sleutel op een plausibel ogende, maar verkeerde plek.

Let op:

• API-sleutels of tokens hardcoded in broncode (gebruikelijk als een AI-assistent snel itereert en gewoon iets werkends wil).
• Secrets die de client bereiken — in local storage, session storage, client-side JavaScript, of cookies zonder de juiste beveiligingsattributen.
• Secrets die in de git-historie terecht zijn gekomen, ook als ze later uit het bestand zijn gehaald.
• .env-bestanden zonder bijbehorende regel in .gitignore — makkelijk te missen bij een project dat snel is opgezet.

De oplossing is zelden ingewikkeld. Het probleem is dat niemand keek, omdat de code compileerde en de functie werkte.

3. Inputvalidatie: wat gebeurt er bij onverwachte invoer?

Dit is de categorie die elke checklist noemt — maar AI-gegenereerde code heeft een specifiek patroon: validatie die op het gelukkige pad bestaat en nergens anders.

Let op:

• Gebruikersinvoer die direct in HTML, databasequery's of shell-commando's belandt zonder sanitatie.
• Validatie die alleen in de frontend gebeurt, zonder controle zodra het verzoek de backend bereikt.
• Ontbrekende grenscontroles op bestandsuploads, array-indices of numerieke velden — onzichtbaar tot iemand (of iets geautomatiseerds) een randgeval probeert.
• Query's die met string-concatenatie worden opgebouwd in plaats van parameterized queries of een ORM.

Niets hiervan is nieuw beveiligingsdenken. Nieuw is het volume: als een AI-model tientallen functies per sessie genereert, wordt de kans dat validatie overal consistent is kleiner, niet groter.

4. Over-fetching: hoeveel data is er echt nodig?

Dit is de categorie die bijna elke generieke vibe coding-checklist overslaat, en een van de problemen die wij het vaakst zien.

Als een AI-agent een nieuwe functie koppelt aan een bestaand systeem — je ERP, CRM, Gmail, Outlook — grijpt hij vaak naar de breedste, simpelste API-aanroep: "haal alle klantrecords op" in plaats van "haal de orderhistorie van deze ene klant op". Dat werkt bij het testen met een kleine dataset. Het wordt een echt probleem op schaal, en een echt risico als die brede respons ooit wordt gelogd, gecached of verder doorgegeven dan de bedoeling was.

Let op:

• API-aanroepen die hele objecten of tabellen teruggeven terwijl de functie een paar velden toont.
• Data die uit een systeem wordt gehaald en daarna client-side wordt gefilterd, in plaats van gefilterd bij de query.
• Integraties zonder caching of besef van rate limits, die bij elke paginaweergave het gekoppelde systeem bestoken.
• Logs of debug-output die volledige API-responses vastleggen, inclusief velden waar niemand om vroeg.

Dit is precies het soort beslissing dat een AI stilletjes neemt terwijl hij het probleem oplost dat je wél gesteld hebt. Niet kwaadwillend, gewoon het simpelste werkende antwoord — en het simpelste werkende antwoord is niet hetzelfde als veilig.

De checklist, op volgorde

Voor een snelle controle vóór productie, in deze volgorde — rechten en secrets eerst, want die zijn het zwaarst en worden het makkelijkst over het hoofd gezien:

1. Rechten — gebruikt elk service-account, elke API-sleutel en elk endpoint de smalste scope die nog werkt?
2. Secrets — staat elke sleutel en elk token server-side, in een echte secrets-laag, en buiten de git-historie?
3. Inputvalidatie — wordt elke invoer server-side gevalideerd, niet alleen in de interface, met parameterized queries overal?
4. Over-fetching — haalt elke integratie alleen de velden en records op die de functie echt nodig heeft?
5. Security headers en transport — staan HTTPS, CSP, X-Frame-Options en X-Content-Type-Options aan? Moderne hostingpartijen regelen veel hiervan standaard, maar controleer het in plaats van het aan te nemen.
6. Overdraagbaarheid — kan een andere developer dit over een half jaar oppakken zonder de oorspronkelijke keuzes van de AI te moeten reverse-engineeren?

Dat laatste punt telt zwaarder dan het lijkt. Veel AI-gebouwde projecten werken prima bij oplevering en vallen stil zodra de oorspronkelijke bouwer vertrekt, omdat niemand vastlegde waarom de AI deed wat hij deed. Dat patroon zien we zo vaak dat we er apart over schreven in AI-implementatie voor MKB: waarom de meeste pilots vastlopen na de proof-of-concept .

Waar dit past als je al met AI bouwt

Niets hiervan betekent langzamer werken. Discovery, bouw en een werkende tool in één tot drie weken blijft realistisch — deze checklist loopt daarnaast, niet in plaats daarvan, meestal als review die vlak voor livegang wordt ingepland in plaats van als losse fase van weken.

Je hoeft je bestaande stack ook niet te vervangen. Of de AI-gegenereerde code nu op je CRM, ERP of mailbox zit, de review gaat over de koppelvlakken, niet over het slopen en herbouwen van wat al werkt. En niets hiervan vervangt je eigen oordeel of de goedkeuring van je team — een review signaleert risico's; jouw team bepaalt wat er live gaat.

Zit je eerder in het proces en vraag je je vooral af welke handmatige, repeterende processen überhaupt een AI-tool waard zijn? Dat is een andere startvraag, behandeld in AI-automatisering: voorbeelden uit de praktijk . Wil je dat we met je meekijken naar wat er al gebouwd is, plan dan een vrijblijvend gesprek van 30 minuten .

FAQ

Hoe veilig is vibe coding?

Dat hangt volledig af van wat er vóór livegang wordt gecontroleerd, niet van de tool waarmee de code is gegenereerd. AI-modellen schrijven snel werkende code, maar nemen stilzwijgend beslissingen over rechten, opslag van secrets en datatoegang die een werkende demo niet laat zien. Een review vóór productie op precies die punten bepaalt of het resultaat echt veilig is.

Hoe zorg ik dat mijn vibe-coded app veilig is vóór de lancering?

Doe een gestructureerde review voordat er iets bij klanten komt, in vier gebieden op volgorde: rechten (zo smal mogelijk), secrets (alleen server-side, nooit in git-historie of client-side opslag), inputvalidatie (server-side gecontroleerd, niet alleen in de interface) en integraties (alleen de data die een functie echt nodig heeft, geen volledige records of tabellen).

Welke tools heb ik nodig om veilig te vibe coden?

Er is geen verplichte toolset — het proces telt zwaarder. Een secrets-manager, een ORM of laag met parameterized queries, en een review vóór productie zijn het praktische minimum, ongeacht welk AI-model (ChatGPT, Claude, Gemini, Copilot, Mistral) de oorspronkelijke code schreef.

Kan een code review deze problemen nog vinden nadat de AI de code al geschreven heeft?

Ja — dat is juist het moment waarop de meeste van deze problemen worden gevonden. Rechten, secrets, inputvalidatie en de reikwijdte van integraties controleren vlak voor livegang is betrouwbaarder dan proberen een AI-model zo aan te sturen dat het deze fouten niet maakt.