Low-poly miniatuurstad van bovenaf met een grote open laptop in het midden waar alle straten op uitkomen

Vibe coding risico's: je ai-app werkt, maar is hij ook veilig?

Je hebt in een weekend een werkende AI-app gebouwd, maar werkt is nog niet hetzelfde als veilig. Dit zijn de vijf grootste vibe coding risico's en hoe je ze afvangt voordat je live gaat.

Door Green Creatives26 september 2026Bijgewerkt 26 september 20266 min

Je hebt in een weekend met Claude of Cursor een klantportaal, een intaketool of een interne app gebouwd. Hij draait, hij ziet er goed uit en je team gebruikt hem al. Het voelt als de beste investering van het jaar, en dat kan hij ook zijn. Maar een app die werkt is nog geen app die veilig is, en precies in dat verschil zitten de vibe coding risico's die een ondernemer duizenden euro's kunnen kosten.

We zijn zelf voor vibe coding. We bouwen dagelijks met AI en zien hoe snel je daarmee van idee naar werkend product gaat. Wat we ook zien: code die door AI is geschreven en door AI is gecontroleerd, lijkt vaak prima. Pas later, als er echte gebruikers en echte data in zitten, komen de gaten boven. In dit artikel lees je welke risico's het grootst zijn, waarom AI ze zelf over het hoofd ziet en hoe wij ze afvangen voordat iets live gaat.

De vijf grootste vibe coding risico's

De meeste waarschuwingen die je online ziet komen uit de Verenigde Staten. De mechanismen zijn hier hetzelfde, alleen heten de regels anders. Dit zijn de vijf risico's die wij het vaakst tegenkomen.

1. Een simpele website met een onbegrensde rekening

Een statische site op een platform als Netlify of Vercel kost je normaal niets. Totdat iemand hem bestookt met nepverkeer. In 2024 kreeg een ontwikkelaar voor een simpele hobbysite een rekening van $104.500 na een DDoS-aanval. Netlify schold de rekening pas kwijt nadat het verhaal viraal ging op Hacker News. Veel van deze platforms rekenen per gigabyte en hebben standaard geen harde bovengrens. Een AI-assistent die je site deployt, stelt die grens niet vanzelf in.

2. Een database die voor iedereen openstaat

Tools als Lovable en Bolt bouwen standaard op Supabase. Daar bepaalt row level security (RLS) wie welke gegevens mag zien. Staat die uit, dan kan iedereen met de publieke sleutel uit je JavaScript je complete klantentabel uitlezen. Een onderzoeker scande in 2025 ruim 1.600 apps uit de showcase van Lovable en vond bij 170 daarvan, ruim 10 procent, kritieke lekken. Voor een Nederlands bedrijf is dat direct een datalek onder de AVG, met een meldplicht bij de Autoriteit Persoonsgegevens binnen 72 uur.

3. API-sleutels in je code en functies die zichzelf aanroepen

AI zet sleutels van OpenAI, Stripe of je mailprovider graag rechtstreeks in de code, omdat het dan meteen werkt. Eenmaal gedeployed staan ze open en bloot. Een tweede klassieker is een functie die zichzelf blijft aanroepen. Een startup verbrandde in 2020 zo in een paar uur $72.000 aan Google Cloud tijdens een test. Budgetwaarschuwingen hielpen niet: die sturen een mail, maar zetten niets stil.

4. Een site die niet toegankelijk is

Sinds 28 juni 2025 geldt de European Accessibility Act. Webshops, online bankdiensten en andere digitale diensten voor consumenten moeten dan toegankelijk zijn: bedienbaar met toetsenbord, afbeeldingen met alt-tekst, voldoende contrast. Micro-ondernemingen die diensten leveren zijn vrijgesteld, maar wie groter is en een AI-gebouwde site laat draaien zonder controle, loopt een reëel risico. AI levert visueel mooie interfaces, maar toegankelijkheid zit er zelden standaard in.

5. Ongevraagde berichten naar je wachtlijst

Je lanceert, dus je mailt of sms't iedereen die zich ooit heeft aangemeld. Onder de Telecommunicatiewet heb je voor commerciële elektronische berichten vooraf toestemming nodig, en de AVG vraagt dat je die toestemming kunt aantonen. De ACM handhaaft hierop. Een formulier dat AI in een uur bouwt, legt die toestemming meestal niet goed vast.

Waarom AI zijn eigen gaten niet ziet

De logische reactie is: dan laat ik AI mijn code toch controleren. Dat doen wij ook, en het helpt. Maar het is niet genoeg. Onze ervaring is dat een AI-review vaak concludeert dat alles in orde is, terwijl je bij verder bouwen stap voor stap gaten in de code ontdekt. Een ontbrekende rechtencheck hier, een sleutel die toch in een build terechtkwam daar.

Dat komt doordat een taalmodel optimaliseert voor code die werkt, niet voor code die bestand is tegen iemand die hem probeert te misbruiken. Het test het pad dat jij beschrijft, niet het pad dat een aanvaller kiest. Ook bij klanten die met een zelfgebouwde of goedkoop gebouwde app bij ons aankomen, zien we dit patroon terug. Details delen we niet, want daar werken we onder NDA. Het patroon is wel steeds hetzelfde: het product doet wat het moet doen, en daarom kijkt niemand verder.

Hoe wij vibe coding risico's afvangen

We bouwen zelf ook met AI, alleen met een vast controleproces eromheen. Dat maakt het verschil tussen een prototype en een product dat je met een gerust hart aan klanten geeft.

Twee AI's die elkaar controleren. We laten twee toonaangevende modellen dezelfde code onafhankelijk doorlichten en zetten ze tegen elkaar in om gaten te vinden. Wat het ene model mist, vindt het andere vaak wel. Daarna loopt een developer de bevindingen na, want eindredactie blijft mensenwerk.

Een vaste checklist vóór livegang. Elke oplevering gaat langs dezelfde lijst: rechten per databasetabel, sleutels, rate limits, toegankelijkheid en toestemmingen. Dat is saai werk, en juist daarom doen we het niet op gevoel.

Self-hosted Supabase. We draaien Supabase op eigen servers. Row level security richten we per tabel in, en je klantdata blijft binnen de EU. Dat sluit aan bij hoe we ook met Europese taalmodellen op eigen infrastructuur werken.

Geen sleutels in de code en elke API gemonitord. API-sleutels krijgen een vervaldatum en komen nooit in een deploy terecht. We houden het gebruik van elke API bij, zodat een functie die op hol slaat opvalt voordat de rekening binnenkomt, niet erna.

Toegankelijk vanaf de eerste versie. We bouwen volgens de eisen van de European Accessibility Act, en klanten vragen daar inmiddels ook actief naar.

Zelf bouwen of laten bouwen?

Vibe coding is een uitstekende manier om een idee te testen, een intern hulpmiddel te maken of te laten zien wat je bedoelt. Zolang er geen klantdata, betalingen of publieke toegang in het spel zijn, is het risico beperkt. Zodra een van die drie erbij komt, laat je een developer meekijken voordat je live gaat.

Wil je het goed geregeld hebben vanaf het begin? Dan bouwen wij het voor je. Ook wij doen dat met AI, want daarmee ben je snel, maar met de controles die AI zelf overslaat. Van AI-implementatie en automatisering tot maatwerk webapps en websites. Heb je al iets gebouwd en wil je weten hoe het ervoor staat? Plan een gesprek, dan kijken we er samen naar.

Bronnen

Veelgestelde vragen

Wat zijn de grootste vibe coding risico's?

Onbeveiligde databases, API-sleutels in de code, onbegrensde hostingkosten, gebrek aan toegankelijkheid en berichten zonder vastgelegde toestemming.

Is een app gebouwd met Lovable of Bolt onveilig?

Niet per definitie. Het platform zelf is niet het probleem. De gegenereerde app mist vaak beveiligingsinstellingen zoals row level security, tenzij iemand die bewust inricht en controleert.

Kan ik mijn AI-code niet gewoon door AI laten controleren?

Dat helpt, maar het is niet genoeg. Wij zien dat een AI-review vaak groen licht geeft terwijl er later toch gaten opduiken. Laat een developer het eindoordeel geven.

Geldt de European Accessibility Act voor mijn bedrijf?

De wet geldt sinds 28 juni 2025 voor onder meer webshops en online diensten voor consumenten. Micro-ondernemingen die diensten leveren, met minder dan 10 medewerkers en maximaal €2 miljoen omzet, zijn vrijgesteld.

Wanneer moet ik een developer inschakelen?

Zodra je app klantdata opslaat, betalingen verwerkt of publiek toegankelijk wordt.