Vibe coding: waarom 45% van AI-code kwetsbaar is

Vibe coding, software bouwen met AI zonder zelf code te schrijven, is de snelste manier om iets te lanceren. Het is ook de snelste manier om je database te lekken. Het Moltbook-incident bewees dat: 4.75 miljoen records gelekt binnen een dag. Onderzoek toont dat 45% van AI-gegenereerde code security vulnerabilities bevat. Dit artikel laat zien waar het misgaat en wat je eraan doet.

4.75 miljoen records gelekt in één dag

Januari 2025. Moltbook gaat viraal. Een sociaal netwerk waar AI-agents met elkaar praten. Binnen een week 1.5 miljoen “agents” geregistreerd. De oprichter claimt trots: “Ik heb geen enkele regel code geschreven.”

Dat klopte. En dat was precies het probleem.

Security onderzoekers van Wiz vonden binnen minuten een open deur. De Supabase API-sleutel stond gewoon in de JavaScript. Geen Row Level Security geconfigureerd. Resultaat: volledige toegang tot de database. Lees én schrijf.

Wat er gelekt werd:

• 4.75 miljoen database records
• 1.5 miljoen API-tokens
• 35.000 e-mailadressen
• OpenAI API-sleutels in plaintext berichten

De fix duurde minder dan 4 uur. Maar de schade was gedaan.

Disclosure timeline:

• 31 januari 2026, 21:48 UTC, Wiz Research neemt contact op met Moltbook
• 1 februari 2026, 01:00 UTC, alle tabellen beveiligd

Drie uur. Zo snel kan het gefixt worden. De vraag is waarom het überhaupt kon gebeuren.

Interessant detail: terwijl Moltbook claimde 1.5 miljoen “agents” te hebben, toonde de database slechts 17.000 menselijke eigenaren. Een ratio van 88:1. Het platform was grotendeels bots die met bots praatten, maar de gelekte API-sleutels en e-mailadressen waren echt.

Wat is vibe coding eigenlijk?

Vibe coding is software bouwen door AI-prompts zonder zelf code te schrijven of te begrijpen. Je beschrijft wat je wilt, de AI genereert het, je deployt het. Klaar. Binnen een uur heb je een werkend product. Binnen een dag kan je database gelekt zijn.

Het werkt. Het is snel. En het is gevaarlijk als je niet weet wat je doet.

We gebruiken het zelf ook. Bij het bouwen van ibgids.nl en certificeerwijzer.nl hebben we veel code laten genereren door Claude en Copilot. In de eerste weken vonden we meerdere hardcoded API-sleutels in onze eigen AI-gegenereerde code. Gitleaks ving ze op voordat ze in Git terechtkwamen. Het verschil: we reviewen alles. We snappen wat de code doet. We checken security-instellingen.

Dit is overigens niet het enige AI-gerelateerde security risico. 12% van AI skills blijkt malicious, ontworpen om data te stelen. Het probleem is breder dan alleen code.

Dat laatste gebeurt vaak niet.

De cijfers zijn niet best

Veracode onderzocht in 2025 AI-gegenereerde code op security:

Dat is niet een beetje slecht. Dat is bijna de helft van alle code.

En het wordt erger. AI-tools genereren code 4x sneller dan mensen. Maar vulnerabilities stapelen ook 4x sneller op. Één op de vijf organisaties heeft al een breach gehad die direct te linken is aan AI-gegenereerde code.

De vijf grootste risico’s

1. Hardcoded credentials

Het Moltbook-probleem. API-sleutels in de frontend JavaScript. Wachtwoorden in config files. Tokens die nooit geroteerd worden.

AI-tools doen dit 2x zo vaak als menselijke developers. Niet omdat de AI dom is, maar omdat de AI optimaliseert voor “het werkt”, niet voor “het is veilig”.

Wat je doet:

• Gebruik environment variables, nooit hardcoded waarden
• Zet Gitleaks als pre-commit hook (gratis, 2 uur opzetten)
• Scan je repository op gelekte secrets met TruffleHog

2. Database misconfigurations

83% van de exposed Supabase databases heeft geen Row Level Security. De database staat gewoon open.

Supabase is ontworpen om met een public key te werken. Dat is veilig, maar alleen als je RLS configureert. Zonder RLS kan iedereen alles lezen en schrijven.

Firebase heeft hetzelfde probleem. “Test mode” blijft vaak aanstaan. ~150 van de ~200 geaudite apps hadden permissive configs.

Wat je doet:

• Enable Row Level Security op elke tabel. Geen uitzonderingen.
• Maak policies die bepalen wie wat mag
• Check of je anon key (niet service key) in de frontend gebruikt

Vergelijkbaar principe geldt voor andere infrastructuur. Zie ook hoe je lokale LLMs veilig installeert, 175.000 Ollama-servers staan open door dezelfde fout: verkeerde configuratie.

3. Slopsquatting: nep-packages met malware

Dit is nieuw. AI hallucineert packages die niet bestaan. 20% van de packages die AI aanraadt, bestaat niet.

Aanvallers hebben dit door. Ze registreren die niet-bestaande package-namen en vullen ze met malware. Jij installeert het onbewust.

Voorbeeld: AI suggereert requests-proxy. Bestaat niet. Aanvaller registreert het op PyPI. Developer installeert het. Malware draait.

In 2025: 440.000 hallucinated dependencies gevonden in 2.23 miljoen onderzochte package-referenties. Malicious uploads naar open-source repos +156%.

Wat je doet:

• Check of packages bestaan: npm info package-name of pip show package-name
• Bekijk de package op npm/PyPI: <10.000 downloads en <6 maanden oud = extra voorzichtig
• Gebruik OWASP Dependency-Track voor SBOM-beheer (gratis)
• Kijk naar download-aantallen en maintenance-status

4. Missing input validation

AI optimaliseert voor de “happy path”. Gebruiker vult formulier correct in, data wordt opgeslagen, klaar.

Maar wat als iemand SQL injection probeert? Of een script in een inputveld plakt? AI denkt daar niet aan.

86% van AI-gegenereerde code faalt op XSS-preventie. SQL injection blijft een top-probleem.

Wat je doet:

• Valideer alle input server-side (niet alleen in de UI)
• Gebruik parameterized queries, nooit string concatenation
• Laat Semgrep in je CI/CD pipeline draaien (gratis tier beschikbaar)

5. Te veel vertrouwen in AI-output

Dit is misschien het grootste probleem. AI-code ziet er goed uit. Het werkt. Het heeft comments. Het lijkt professioneel.

Maar het mist context. De AI weet niet dat je authentication nodig hebt. Of dat die functie ook via de API aangeroepen kan worden, niet alleen via de UI.

Wat je doet:

• Behandel AI-code als code van een externe bron
• Review op gedrag, niet op syntax
• Vraag: “Wat gebeurt er als iemand de UI omzeilt?”

Vijf maatregelen die je vandaag kunt nemen

Dit kost je een dag. Misschien twee. Allemaal gratis.

Een minimum AI governance policy

Dit hoeft niet ingewikkeld:

Goedgekeurde tools: ChatGPT Plus, Claude Pro, GitHub Copilot

Verboden data in AI tools:

• Klantgegevens
• Wachtwoorden en API keys
• Financiële records

Verplichte procedures:

• Alle AI-gegenereerde productie-code wordt gereviewd
• Dependencies worden gecheckt voordat ze geïnstalleerd worden
• Bij twijfel: behandel data als gevoelig

Dat is het. Eén pagina. Communiceer het naar je team.

De roadmap voor de komende maand

Week 1-2: Basis

• Schrijf en deel de governance policy
• Installeer Gitleaks pre-commit hooks
• Audit alle Supabase/Firebase configuraties

Week 3-4: Automatisering

• Zet Semgrep in je CI/CD pipeline
• Maak een code review checklist voor AI-code
• Enable security scanning in GitHub/GitLab

Maand 2+: Doorontwikkeling

• Implementeer Dependency-Track voor SBOM
• Wijs een security champion aan (tip: dit helpt ook bij audits, auditors vragen steeds vaker naar AI-governance)
• Plan de eerste security awareness sessie

Na 4 weken heb je de basis staan. Na 8 weken ben je audit-ready.

Wat we hiervan leren

Vibe coding is niet het probleem. Het is een tool. Een krachtige tool die je 4x sneller laat bouwen.

Het probleem is vibe coding zonder na te denken over security. Zonder te reviewen wat de AI maakt. Zonder te checken of je database-instellingen kloppen.

Moltbook had geen regels code geschreven. Maar ze hadden ook geen security-instellingen gecontroleerd.

Wij bouwen ook met AI. Veel zelfs. Maar we reviewen alles. We snappen wat de code doet. We checken de configuraties.

Dat is het verschil tussen snel bouwen en snel falen. Er zit een heel spectrum tussen vibe coding en verantwoord bouwen met AI. We beschrijven de vier niveaus van AI-coding, van blind accepteren tot maximale controle.

Wil je weten hoe je AI veilig en structureel inzet in je bedrijf? Lees onze 7 stappen om AI-native te worden, inclusief hoe je vangrails opzet zonder bureaucratie.

Hulp nodig?

Wil je weten of jouw AI-gegenereerde code veilig is? We doen een quickscan van je Supabase/Firebase configuratie en kijken naar je grootste risico’s. Duurt 30 minuten, geen verplichtingen.

Plan een gesprek →

Bronnen: Wiz Research, Hacking Moltbook, Infosecurity Magazine, Axios, Moltbook security threats, Veracode GenAI Security Report 2025, OWASP Top 10 for LLM Applications 2025