Maak deze securityfouten niet bij het vibecoden

Welke securityfouten moet je niet maken bij het Vibecoden? Het zal je wellicht bekend zijn: vibecoden wordt steeds populairder. Hierbij gebruik je AI om te programmeren. Dat levert tijdswinst op, maar het stelt je ook bloot aan allerlei veiligheidsproblemen. Databases die totaal gewist worden, API-sleutels die lekken of persoonlijke informatie die op straat ligt: het is allemaal geen uitzondering meer. In dit artikel leggen we je uit hoe je deze problemen voorkomt.

Wat is vibecoden en waarom is security zo belangrijk?

Vibecoden betekent dat je snel werkende code met behulp van AI genereert. Je beschrijft wat je wilt en AI maakt het. Binnen enkele minuten heb je een werkend prototype. En zo moet je het ook beschouwen: als een prototype. Het is nog niet geschikt om openbaar te gebruiken, want vaak ontbreken belangrijke security-checks.

Dat is ook logisch, want AI weet niet wat gevoelig is in jouw specifieke context. Jij bent de enige die dat weet en je bent ook de enige die verantwoordelijk is. Je kunt niet bij een datalek zeggen: ‘Oh, maar ik wist het niet, want AI heeft het gemaakt.’ Daarmee stel je jezelf bloot aan aansprakelijkheidsrisico’s.

Fout 1: onbewust gedeelde .env keys

ENV-bestanden bevatten database-URL’s, OAuth-secrets, betaalprovider-API-sleutels en andere belangrijke informatie. Het is de bedoeling dat deze informatie binnen jouw systeem blijft. Zijn ze publiekelijk te lezen, dan is je hele systeem eigenlijk al niets meer waard. AI-modellen kunnen deze input opslaan voor training of logging, en daarmee wordt alles publiek.

Wat je moet doen: gebruik altijd placeholders zoals ‘DATABASE_URL = <jouw-url-hier>’ als je configuraties deelt met AI. Voeg .env altijd toe aan je .gitignore en gebruik tools als git-secrets of trufflehog om automatisch te scannen op gelekte credentials. Roteer alle sleutels regelmatig.

Fout 2: API-keys die rondzwerven in je codebase

Er zijn al verschillende mensen wakker geworden met een torenhoge rekening. Geautomatiseerde bots gaan op zoek naar API-keys die zijn gekoppeld aan AI-generatoren als Claude, Gemini en ChatGPT. Deze keys zijn zo gewild omdat kwaadwillenden hiermee op jouw kosten AI-antwoorden kunnen genereren.

Heb je je key al per ongeluk gelekt via GitHub, dan is deze key voor eeuwig besmet. Hij blijft namelijk beschikbaar in git log. In dit geval moet je direct nieuwe keys aanmaken. Om dit scenario te voorkomen is het belangrijk dat je API-keys altijd opslaat in omgevingsvariabelen. Schrijf ze niet letterlijk op in je code of in je prompt aan AI. Stel daarnaast uitgavelimieten in via het dashboard van je AI-provider. Gewoon voor het geval dat het eens fout gaat. Zo voorkom je dat een ogenschijnlijk klein foutje een dure ramp wordt.

Fout 3: AI die per ongeluk je hele database verwijdert

Stel je vraagt de AI: ‘verwijder alle oude gebruikers uit de database.’ De AI genereert dan een query: ‘DELETE FROM users WHERE created_at < ‘2023-01-01’’. Heel logisch vanuit het model, maar daarmee verwijder je misschien ook klanten die je nog nodig hebt. En nog erger: misschien hallucineert AI en verwijdert het meteen je hele users-tabel. Daarmee ben je al je gebruikers kwijt.

Je zult niet het eerste bedrijf zijn dat kostbare data kwijtraakt. Het ging bijvoorbeeld fout bij PocketOS, die Claude Opus 4.6 gebruikte voor het vibecoden. Ontwikkelaar Jer Crane raakte z’n hele productiedatabase kwijt doordat een AI-agent alles verwijderde. Daarna ging de tool nog een stukje verder en verwijderde deze ook meteen alle back-ups. In slechts 9 seconden was het project te gronde gericht.

Wat je moet doen: Geef AI-agents nooit toegang tot de productie-database met schrijfrechten, tenzij je echt niet anders kunt. Werk met read-only databases voor analyse. Wil je zeker weten dat het niet misgaat, gebruik dan staging-omgevingen voor tests en maak altijd back-ups voordat je AI-gegenereerde queries uitvoert. Elke query moet je door een mens laten reviewen, zonder uitzonderingen.

Fout 4: de basisbeginselen niet op orde hebben

Veiligheid behoort tot de basisbeginselen van elke app of website. Daarvoor moet je in ieder geval het volgende gebruiken:

  • Tweefactorauthenticatie
  • HTTPS-verbindingen (versleutelde verbindingen)
  • CORS (zodat willekeurige websites geen gebruik kunnen maken van jouw dienst)
  • Password-hashing met bcrypt of argon2 (zodat kwaadwillenden geen wachtwoorden kunnen ontfutselen)
  • Session management (je wilt niet dat je gebruikers voor eeuwig ingelogd blijven)
  • JWT-validatie (zodat gebruikers kunnen aantonen wie ze zijn)

Wat je moet doen: Een security-checklist als vast onderdeel van je vibecoding-workflow maken. Je kunt deze bijvoorbeeld in een markdown-file zetten, zodat je AI-agent deze checklist altijd doorloopt. Vraag ook expliciet aan AI om rate limiting toe te voegen aan het endpoint, wachtwoorden te hashen met bcrypt en interne foutmeldingen te verbergen voor de eindgebruiker. Security by design begint altijd bij de prompt en niet achteraf.

Fout 5: vergeten inputs te sanitizen

Cross Site Scripting (XSS), SQL-injecties en command injections zijn nog altijd dé manier om in te breken en gevoelige data te stelen. Gebruikersinput is de meest voorkomende aanvalsvector in alle webapplicaties. Vibecoding maakt het probleem alleen maar groter.

Een simpel zoekformulier dat gebruikersinput direct in een SQL-query stopt, geldt als een open deur voor SQL-injectie. Vergeet je een commentaarveld te sanitizen, dan geef je daarmee aanvallers de mogelijkheid om scripts te injecteren die andere gebruikers treffen. AI-gegenereerde code is extreem gevoelig voor eenvoudige inbraken. Waarom? Omdat AI altijd voor de snelste weg kiest.

Wat je moet doen: Gebruik bijvoorbeeld DOMPurify voor HTML-sanitizing en validator.js voor inputvalidatie. Vraag altijd aan je AI-assistent of de code is beschermd tegen SQL-injectie en XSS-lekken.

Veilig vibecoden kan alleen als je zelf nadenkt

Vibecoden lijkt prachtig, maar het is niet geschikt voor mensen die zelf geen ontwikkelervaring hebben. AI is een krachtige assistent, maar geen security-engineer. De fouten die we net beschreven komen niet zelden voor, maar aan de lopende band. AI lijkt snelheid boven veiligheid te verkiezen.

Daarom is het een goed idee om alle AI-gegenereerde code te behandelen alsof het is geschreven door een junior developer die de basisbeginselen van online veiligheid niet kent. Kijk je code uitgebreid na en test het kritisch. Veiligheid is niet iets wat je later toevoegt, maar iets dat al vanaf het begin goed moet zitten.

Scroll naar boven