Vibecoded websites, sites die grotendeels door AI-tools zoals Cursor of GitHub Copilot zijn gegenereerd, bevatten structurele kwetsbaarheden die ze vatbaar maken voor veelvoorkomende aanvallen. Doordat AI-modellen getraind zijn op enorme hoeveelheden publieke code, waarvan een aanzienlijk deel onveilig is, reproduceren ze patronen zonder beveiligingscontext. Het resultaat: functionele code die er betrouwbaar uitziet, maar open deuren biedt voor SQL-injectie, XSS en andere aanvallen. In dit artikel leggen we uit hoe dat komt en wat je eraan kunt doen.
Hoe AI-gegenereerde code beveiligingsgaten creëert #
AI-gegenereerde code creëert beveiligingsgaten doordat de onderliggende modellen getraind zijn op miljoenen codefragmenten uit het publieke domein, waarvan een groot deel onveilige patronen bevat. De AI optimaliseert voor functionaliteit en reproduceert wat statistisch het vaakst voorkomt, niet wat het veiligst is.
Dat uit zich in concrete problemen. Denk aan ontbrekende invoervalidatie, hardcoded credentials in de broncode en onveilige standaardinstellingen voor databases en API’s. Deze patronen komen massaal voor in trainingsdata en worden daardoor als “normaal” beschouwd door het model.
De gevaarlijkste fouten zijn niet de zichtbare syntaxfouten, die zijn juist sterk afgenomen. Het zijn de architecturale zwakheden: privilege-escalatiepaden en ontwerpfouten die diep contextueel redeneren vereisen om te herkennen. Precies het type redenering waar AI-modellen niet voor gebouwd zijn.
Daar komt een supply chain-risico bij: AI-tools suggereren soms dependencies die helemaal niet bestaan. Aanvallers registreren die niet-bestaande pakketnamen vervolgens in publieke repositories en vullen ze met kwaadaardige code. Dit fenomeen, bekend als “slopsquatting”, maakt vibecoded projecten extra kwetsbaar voor dit type aanval.
De meest voorkomende aanvallen op vibecoded sites #
De aanvallen die het vaakst succesvol zijn op vibecoded websites zijn SQL-injectie, cross-site scripting (XSS), onbeveiligde API-endpoints en gebrekkig sessiebeheer. Deze kwetsbaarheden komen zo vaak voor omdat AI-tools consequent onveilige patronen genereren voor precies deze categorieën.
SQL-injectie ontstaat doordat AI-tools veelvuldig raw string-concatenatie gebruiken in plaats van geparametriseerde queries. Een prompt als “maak een zoekfunctie voor gebruikers” levert werkende code op die gebruikersinput rechtstreeks in SQL-queries plakt, een open uitnodiging voor aanvallers om je database te manipuleren.
XSS is minstens zo problematisch. Het overgrote deel van AI-gegenereerde code slaagt er niet in gebruikersinput te sanitizen voordat het in de browser wordt weergegeven. XSS-bescherming vereist inzicht in welke variabelen van gebruikers afkomstig zijn en hoe ze door de applicatie stromen, context die AI-tools niet consistent bijhouden.
Daarnaast missen vibecoded applicaties vrijwel altijd basale beveiligingsheaders en CSRF-bescherming. Hardcoded API-sleutels en credentials worden regelmatig meegedeployed zonder dat iemand de code grondig heeft doorgelezen. Het resultaat is een combinatie van kwetsbaarheden die de websitebeveiliging fundamenteel ondermijnt.
Waarom prompten geen vervanging is voor beveiligingskennis #
Een goed geformuleerde prompt verbetert de kwaliteit van AI-gegenereerde code, maar is geen vervanging voor echte beveiligingskennis. Security-gerichte prompts kunnen het aantal veelvoorkomende kwetsbaarheden verminderen, maar een aanzienlijk deel blijft altijd over, zeker wanneer de context van de specifieke toepassing ontbreekt.
Het kernprobleem is dat je alleen de juiste beveiligingsprompts kunt schrijven als je al weet welke kwetsbaarheden mogelijk zijn. AI optimaliseert voor het doel dat je stelt, en dat doel is bijna altijd functioneel: “bouw een loginpagina” of “maak een REST API.” Beveiliging is een non-goal tenzij je het expliciet en gedetailleerd maakt.
AI-modellen missen bovendien de context van jouw specifieke infrastructuur. Ze kennen je dreigingsmodel niet, weten niet welke data gevoelig is en begrijpen niet hoe componenten in jouw omgeving samenwerken. Die contextuele beveiligingslogica is precies wat menselijk toezicht onmisbaar maakt.
Praktische stappen om vibecoded code te beveiligen #
Om het beveiligingsniveau van AI-gegenereerde code te verhogen, zijn concrete maatregelen nodig die verder gaan dan vertrouwen op de AI zelf:
- Handmatige code review: behandel AI-output als code van een junior ontwikkelaar. Alles wordt gereviewed, en auth-flows, betalingen en dataverwerking worden nooit samengevoegd op basis van alleen AI-output.
- Statische analysetools (SAST): voer geautomatiseerde beveiligingsscans uit voordat code de main branch bereikt. Dit vangt hardcoded secrets, zwakke tokens en onveilige configuratiepatronen op.
- Dependency scanning: controleer door AI gesuggereerde pakketten op bron, naamgeving, onderhoud en bekende kwetsbaarheden. Maak een allowlist en vereis integriteitscontroles.
- Minimale rechten: pas het principe van least privilege toe op API’s en databases. Geef geen bredere toegangsrechten dan strikt noodzakelijk.
- Zelfreflectie-prompts: vraag de AI om als security engineer de zojuist gegenereerde code te reviewen op injectiekwetsbaarheden, ontbrekende validatie en hardcoded credentials.
Een snelle basistest die iedereen kan uitvoeren: probeer script-tags in invoervelden (XSS-check) en SQL-achtige input in zoekfuncties. Als het gedrag verandert, heb je een probleem.
Veilig bouwen met AI binnen bestaande processen #
De oplossing is niet om AI-tools te verbieden, maar om ze te integreren binnen een gecontroleerde ontwikkelworkflow. Organisaties die AI-ondersteunde ontwikkeling verantwoord willen inzetten, bouwen beveiligingseisen in elke fase van het ontwikkelproces in.
Dat begint met het vastleggen van beveiligingsstandaarden in herbruikbare prompts en templates, zodat elke ontwikkelaar dezelfde basislijn hanteert. Daarnaast is een governance-framework essentieel dat vastlegt welke AI-tools zijn toegestaan, hoe gegenereerde code wordt gereviewed en wie verantwoordelijk is voor de output.
Het belangrijkste principe blijft menselijk toezicht. AI versnelt het bouwproces, maar de verantwoordelijkheid voor websitebeveiliging ligt bij mensen die de context begrijpen, je infrastructuur, je data, je dreigingsmodel. Door beveiliging als standaardonderdeel van je workflow in te richten in plaats van als laatste controle, bouw je veilig zonder snelheid in te leveren.
Wil je weten hoe jouw organisatie ervoor staat op het gebied van beveiliging en compliance binnen het Microsoft Power Platform? Wij helpen je graag met onze Compliance & Security Scan, waarmee we alle Power Apps en Power Automate flows in kaart brengen en analyseren op risico’s en kwetsbaarheden. Neem gerust contact met ons op voor een vrijblijvend gesprek.