Vibecoden met Lovable? Hier moet je op letten
Lovable, Bolt en andere platforms maken bouwen makkelijker dan ooit. Maar beveiliging, rate limits en je database, dat is jouw probleem.
Oscar — TechTovenaar
Je hebt een idee. Je opent Lovable, typt wat je wilt bouwen, en binnen een uur staat er iets. Een echte app, met een inlogscherm, een database en een werkende interface. Het voelt als magie.
En eerlijk gezegd, dat is het ook een beetje.
Maar er is een verschil tussen iets dat eruitziet als een app en iets dat klaar is om echte gebruikers op los te laten. Dat verschil zit hem niet in de knopjes of de kleur van je logo. Het zit in de dingen die je niet ziet.
Wat is vibecoden eigenlijk?
Vibecoden is het idee dat je een AI, zoals Lovable, Bolt, of Replit Agent, vertelt wat je wilt bouwen, en dat die tool de code voor je schrijft. Je stuurt bij met tekst, de AI past aan. Je hebt nauwelijks technische kennis nodig om iets werkends op te leveren.
Lovable is op dit moment waarschijnlijk de bekendste in Nederland en België. De tool genereert een complete React-app, koppelt automatisch aan Supabase voor je database en authenticatie, en je kunt binnen een dag live gaan. Bolt.new doet iets vergelijkbaars, Cursor is meer voor developers die al kunnen coderen maar sneller willen gaan, en Replit heeft zijn eigen hosted omgeving.
Ze zijn allemaal nuttig. En ze hebben allemaal dezelfde blinde vlek.
Beveiliging: de grootste valkuil
Een AI schrijft code die werkt. Maar werken en veilig zijn, dat is niet hetzelfde.
Het grootste probleem dat je tegenkomt bij vibe-coded apps: Row Level Security is standaard vaak uitgeschakeld. Lovable gebruikt Supabase als database. Supabase heeft een uitstekend beveiligingssysteem, RLS genaamd, waarmee je per gebruiker bepaalt wie welke data mag zien. Maar als jij (of de AI) dat niet expliciet inschakelt, kunnen gebruikers elkaars data opvragen. Gewoon via de API. Zonder hacking, zonder kennis, puur doordat de beveiliging ontbreekt.
Dit is geen theorie. Het is al meerdere keren publiekelijk misgegaan met Lovable-apps in productie.
Daarnaast: API-sleutels. Lovable genereert soms code waarbij gevoelige sleutels direct in de frontend terechtkomen. Alles wat in je browser draait, is leesbaar voor iedereen die de broncode inspecteert. Dat geldt voor je Supabase-sleutel, maar ook voor koppelingen met OpenAI, Stripe of welke andere dienst dan ook.
Rate limits: wat gebeurt er als het werkt?
Stel dat je app aandacht krijgt. Honderd gebruikers tegelijk, misschien duizend. De meeste vibe-coded apps zijn hier niet op voorbereid.
Supabase heeft limieten op het gratis plan. OpenAI heeft limieten per minuut. Je eigen backend, als er al een is, heeft misschien helemaal geen bescherming tegen herhaalde verzoeken. Zonder rate limiting kan één boze gebruiker, of gewoon een bot, je dienst platleggen of je rekening de lucht in laten gaan.
Dit is geen rampscenario, dit is gewoon wat er gebeurt. Zorg dat je begrijpt welke limieten er gelden op elke dienst die je app gebruikt, en bouw daar bescherming omheen voordat je live gaat.
De database is niet jouw speelgoedkast
Lovable en vergelijkbare tools geven je razendsnel een werkende database. Maar een database in productie vereist discipline die een AI niet automatisch toepast.
Denk aan:
- Backups. Supabase maakt automatisch snapshots op betaalde plannen, maar op gratis plannen is dat beperkter. Weet jij wanneer de laatste backup is gemaakt?
- Datavalidatie. De AI schrijft formulieren, maar controleert de input wel degelijk server-side? Of accepteert je app alles wat erin wordt getypt?
- Soft deletes vs. hard deletes. Als een gebruiker iets verwijdert, is het dan echt weg? Wil je dat?
Niets hiervan is onoplosbaar. Maar je moet er wél bewust over nadenken, want de AI doet dat niet voor je.
Denk in Zero Trust
Het klassieke beveiligingsmodel is: buiten slecht, binnen veilig. Zorg dat de omheining hoog genoeg is, en dan is alles achter die omheining te vertrouwen.
Dat werkt niet meer, zeker niet voor webapps.
Zero Trust gaat ervan uit dat niets en niemand automatisch vertrouwd is, ook niet als iemand al is ingelogd. Elke actie wordt geverifieerd. Elke gebruiker heeft alleen toegang tot wat hij nodig heeft. Geen uitzonderingen voor gemak.
Voor een vibe-coded app betekent dit concreet: stel RLS in, gebruik server-side validatie, geef gebruikers minimale rechten, en ga er nooit vanuit dat de frontend de laatste verdedigingslinie is. Want dat is hij niet.
Wat moet je dan doen voordat je live gaat?
Een snelle checklist:
- RLS ingeschakeld op alle Supabase-tabellen
- Geen gevoelige API-sleutels in de frontend
- Rate limiting op je belangrijkste endpoints
- Authenticatie getest: kan gebruiker A bij de data van gebruiker B?
- Backupstrategie
- Weet wat er gebeurt als je dienst 10x zoveel verkeer krijgt
Dit klinkt als veel. En dat is het vaak ook, als je er voor het eerst mee bezig bent.
Wat vibecoden uitstekend doet: een idee snel tastbaar maken. Valideren of iets werkt. Een prototype tonen aan investeerders of klanten. Dat is echte waarde.
Wat het niet doet: een productie-klare, veilige applicatie opleveren die bestand is tegen echte gebruikers, echte aanvallen en echte druk.
Het gat daartussenin, dat is waar het wél technische kennis vereist. Ik help startups, zzp-ers en MKB-bedrijven om precies dat gat te dichten, van beveiligingsaudit tot schaalbare architectuur. Benieuwd? Laten we kennismaken.