The Moltbook Breach: Wanneer Vibe Coding een Beveiligingsnachtmerkte Wordt

Wat Er Eigenlijk Gebeurde bij Moltbook?

Laat me precies uitleggen wat er misging, want de details zijn belangrijk.

Moltbook is gebouwd met Supabase — een populaire open-source Firebase-alternatief dat gehoste PostgreSQL-databases biedt. Supabase is de backend van keuze voor vibe-coded applicaties omdat het authenticatie, databases en opslag afhandelt met minimale configuratie.

Het probleem? Iemand (of een AI) heeft een Supabase API-sleutel rechtstreeks in de client-side JavaScript-code gezet. Dit is een fundamenteel beveiligingsfout. API-sleutels horen op de server, nooit in code die draait in de browser van een gebruiker.

Maar het wordt erger.

Die API-sleutel had volledige lees- en schrijftoegang tot de volledige database. En Moltbook had Row Level Security (RLS) niet ingeschakeld — een Supabase-functie die bepaalt wie welke data kan benaderen. RLS is zo optioneel als een veiligheidsgordel. Je denkt misschien dat je het niet nodig hebt totdat je crasht.

Beveiligingsonderzoekers van Wiz vonden de blootgestelde sleutel binnen enkele minuten nadat ze naar de website keken. Ze hadden kunnen:

• 1,5 miljoen API-sleutels gedownload (inclusief sleutels voor OpenAI, Anthropic en andere AI-aanbieders)
• Toegang tot privéberichten tussen AI-agenten
• Gewijzigd of verwijderd van gegevens in de database
• Elk gebruikersaccount gehackt
• Loop enorme rekeningen op met gestolen API-sleutels

De klap? De oprichter gaf toe dat hij het hele platform "vibe-coded" had. Geen code review. Geen beveiligingsaudit. Alleen prompts naar een AI en de resultaten kopiëren en plakken.

Waarom gebeurt dit steeds?

Hier is wat frustrerend is aan dit verhaal: het is niet uniek.

Onthoud toen DeepSeek hun API-sleutels blootlegde? Of Base44? Het patroon herhaalt zich omdat de vibe-coding-filosofie actief de praktijken ontmoedigt die deze inbreuken voorkomen.

De kernfilosofie van vibe coding is: ga snel, focus op resultaten, maak je geen zorgen over details. Het is verleidelijk omdat — eerlijk gezegd — het werkt voor het bouwen van prototypes. Je kunt in een paar uur een werkende app draaien.

Maar productieapplicaties leven in een andere wereld. Ze omgaan met echte gebruikersdata, echte betalingen, echte beveiligingsbedreigingen. Dezelfde mindset die je helpt een prototype in een weekend te shipperen, zal je productie-app op dag één hacken.

Ik heb gesproken met een beveiligingsonderzoeker die gespecialiseerd is in AI-gegenereerde code. Hier is wat hem wakker houdt:

• Geen begrip van wat er gebeurt: Wanneer je een AI vraagt om "een inlogssysteem te bouwen", krijg je code die eruitziet als een inlogssysteem maar subtiele fouten kan bevatten die alleen een expert zou opmerken
• Vertrouwen in AI: Gebruikers gaan ervan uit dat AI gegenereerde code veilig is omdat... het van AI is? Die aanname is volledig fout
• Ontbrekende fundamenten: Vibe-coders weten vaak niet wat ze niet weten over beveiliging

Het 45%-probleem

Laat me je een getal geven dat je wakker moet houden: 45%.

Dat is het percentage AI gegenereerde code dat beveiligingskwetsbaarheden bevat, volgens Veracodes onderzoek naar AI gegenereerde softwarebeveiliging^[1].

Dit gaat niet over slechte AI-modellen of onbekwame ontwikkelaars. Het gaat over de fundamentele aard van codegeneratie. AI-modellen zijn getraind op bestaande code — waaronder onveilige code. Ze reproduceren patronen die ze hebben gezien, waaronder kwetsbare.

Veelvoorkomende kwetsbaarheden in AI gegenereerde code:

De Moltbook-inbreuk was eigenlijk twee problemen: een hardcoded API-sleutel (hardcoded geheimen) EN ontbrekende RLS (onveilige configuratie). De ene alleen zou al slecht zijn. Samen creëerden ze een catastrofe.

Wat Niemand Je Vertelt Over Vibe Coding

Laat me eerlijk tegen je zijn. Ik heb vibe coded genoeg projecten. Het heeft echt veranderd hoe ik dingen bouw. Maar ik heb ook harde lessen geleerd op de harde manier.

Je moet nog steeds beveiliging begrijpen

Hier is een ongemakkelijke waarheid: je kunt geen AI-tools gebruiken om veilige applicaties te bouwen als je de beveiliging zelf niet begrijpt. De AI kent je dreigingsmodel niet. Het weet niet welke activa je beschermt. Het genereert gewoon code die er redelijk uitziet.

Je hoeft geen beveiligingsexpert te worden. Maar je moet wel begrijpen:

• Plaats nooit geheimen in client-side code
• Activeer altijd Rijbewijsniveau-beveiliging op databases
• Gebruik omgevingsvariabelen voor gevoelige configuratie
• Implementeer juiste inputvalidatie
• Voer beveiligingsscans uit op gegenereerde code

Snel Prototyperen, Dan Ingenieurswerk

Mijn huidige workflow:

• Vibe code de prototype — Krijg iets werkend, valideer het idee met echte gebruikers
• Identificeer product-marktfit — Voor je ergens in investeert
• Hernieuwen voor productie — Dit is waar je daadwerkelijk beveiliging, prestaties en onderhoudbaarheid engineerd

De fout is het shipperen van vibe-coded prototypes direct naar productie zonder de refactor-stap. Je bespaart geen tijd — je bouwt technische schuld op die je later zal kosten.

Gebruik het juiste gereedschap voor de klus

Dit kan controversieel zijn, maar ik vind vibe coding niet geschikt voor:

• Applicaties die gevoelige gebruikersgegevens verwerken (gezondheidszorg, financiën)
• Systemen die betalingen verwerken
• Alles met regelgevingsvereisten
• Toepassingen waar beveiligingsfouten echte schade kunnen veroorzaken

Voor interne tools, MVPs en prototypen? Ga los. Voor productiesystemen die echte gebruikersdata verwerken? Bouw het goed.

Hoe je jezelf kunt beschermen

Als je vibe coding doet (en eerlijk gezegd, je moet het doen — het is ontzettend krachtig), hier is hoe je de volgende koppenkopie kunt voorkomen:

Voor je Supabase/Backend

javascript
// WRONG - Never do this
const supabase = createClient('https://xxx.supabase.co', 'YOUR_ANON_KEY_HERE')
// Your service_role key is also exposed here!

// CORRECT - Use environment variables, server-side only
const supabase = createClient(
  process.env.SUPABASE_URL,
  process.env.SUPABASE_ANON_KEY
)

Essentiële beveiligingschecklist

• [ ] Rijniveau-beveiliging inschakelen op ALLE databasetabellen
• [ ] Sla API-sleutels op in omgevingsvariabelen, nooit in code
• [ ] Beveiligingsscan uitvoeren op alle gegenereerde code (Snyk, CodeQL of GitHub Advanced Security)
• [ ] Service_role-sleutels nooit aan de client blootstellen
• [ ] Implementeer juiste inputvalidatie op alle gebruikersinvoer
• [ ] Snelheidsbeperking instellen om misbruik te voorkomen
• [ ] Laat een penetratietest uitvoeren voordat je lanceert met echte gebruikers

Hulpmiddelen die helpen

Wat Dit Betekent voor de Industrie

Ik ben eerlijk gezegd bezorgd over waar we naartoe gaan.

We zitten midden in een enorme verschuiving in hoe software wordt gebouwd. Niet-technische oprichters kunnen nu geavanceerde toepassingen maken. De drempel voor instap is ingestort. Dat is opwindend.

Maar we creëren ook een generatie toepassingen waar niemand naar de winkel kijkt.

Hier is wat ik denk dat er moet gebeuren:

• AI-codegereedschappen hebben betere beveiligingsinstellingen nodig — Stop met het genereren van code met ingebakken kwetsbaarheden
• Gemeenschappen moeten hier meer over praten — Elke blogpost over vibe coding moet veiligheid noemen
• We hebben betere tools nodig — Geautomatiseerde beveiligingsscans moeten onderdeel zijn van elke AI-code-werkstroom
• Founders moeten verantwoordelijkheid nemen — Je kunt de AI niet de schuld geven als er iets misgaat

De toekomst van softwareontwikkeling is niet kiezen tussen AI-snelheid en beveiliging. Het is leren ze samen te gebruiken.

Veelgestelde vragen

Het Conclusie

Moltbook is geen uitzondering. Het is een voorproefje van wat komen gaat.

Naarmate meer oprichters vibe-coded toepassingen bouwen zonder beveiligingsfundamenten te begrijpen, zullen we meer inbreuken zien. Meer gelekte API-sleutels. Meer blootgestelde databases. Meer slachtoffers.

Dit is geen argument tegen vibe coding. Het is een argument voor eerlijk te zijn over zijn beperkingen.

Lever snel. Test ideeën. Ga snel vooruit. Maar voordat je echte gebruikersgegevens in gevaar brengt, doe je de beveiligingswerkzaamheden. Je gebruikers vertrouwen je hun informatie toe. Die vertrouwen mag niet op gevoel gebaseerd worden weggelaten.

Verwante Berichten

• Wat Is Vibe Coding? De Complete 2026 Gids
• Cursor vs Windsurf voor Vibe Coding: Welke wint in 2026?
• Hoe bouw je een AI-app in 7 dagen (Stap voor stap
• Hoe krijg je 100 beta-gebruikers snel

Klaar om je app veilig te lanceren? List je app op GetFree—een gecureerde directory waar ontwikkelaars promo codes en beta-toegang delen met duizenden gerichte testers.

Bronnen

Oorspronkelijk gepubliceerd op GetFree.APP Blog — Laatst bijgewerkt: 17 februari 2026