Vibe coding beveiliging: voorkom een datalek in je app
Inhoud
Bob Starr was trots op zijn zelfgebouwde website. Met een AI-tool maakte hij 'Boomberg', een site die liet zien hoeveel Amerikaans belastinggeld naar grote techbedrijven gaat. Hij zette hem meteen online. Pas maanden later, schrijft The Verge, kwam hij erachter dat er een verborgen SQL-injection-lek in zat. Een aanvaller had daarmee data kunnen uitlezen of aanpassen die niemand mocht zien.
Dit is de schaduwkant van vibe coding: je beschrijft in gewone taal wat je wilt, de AI schrijft de code, en binnen een uur staat er iets online. Snel, goedkoop en eerlijk gezegd best verslavend. Maar diezelfde AI bouwt ook fouten in die jij niet ziet, omdat je de code zelf niet kunt lezen.
Voor jou als MKB'er die met Cursor of Replit even snel een handig toolтje bouwt, is dat geen abstract verhaal. Het verschil tussen een leuk experiment en een datalek zit vaak in details die de AI stilletjes overslaat. In deze blog laat ik zien waar het misgaat en hoe je het voorkomt.
Elke dag AI begrijpen, zonder de hype?
Ontvang de gratis MKB AI Quickstart-gids en mijn nuchtere AI-updates. Uitschrijven met 1 klik.
Waarom vibe coding zo verleidelijk is
Vibe coding betekent dat je niet meer zelf regel voor regel programmeert, maar in normale taal vertelt wat je app moet doen. Tools als Cursor, Replit en de modellen van OpenAI vertalen dat naar werkende code. Geen jaren ervaring nodig, geen dure ontwikkelaar: je typt 'maak een formulier waarmee klanten een offerte kunnen aanvragen' en je krijgt een werkend resultaat.
Voor het Nederlandse MKB is dat goud waard. Een interne urenregistratie, een simpel reserveringssysteem, een landingspagina met een aanmeldformulier: dingen waar je vroeger een bureau voor belde, maak je nu zelf in een middag. Ik snap de aantrekkingskracht volledig, en ik gebruik deze tools zelf ook dagelijks.
Het probleem is dat snelheid en veiligheid niet hetzelfde zijn. De AI optimaliseert voor 'het werkt', niet voor 'het is dichtgetimmerd'. En precies dat verschil merk je pas als het te laat is.
Het probleem dat je niet ziet
De fout in de site van Bob Starr heet SQL-injection. Simpel gezegd: een formulierveld waar een bezoeker hoort in te typen, accepteert óók verborgen commando's naar je database. Een kwaadwillende vult dan geen naam in, maar een instructie die zegt 'geef me alle gegevens' of 'verwijder deze tabel'. De database voert dat keurig uit, omdat niemand de AI heeft gevraagd om die invoer eerst te controleren.
Het venijn zit in de timing. Starr ontdekte het lek maanden na de lancering, en alleen omdat iemand hem erop wees. Er stond geen waarschuwing, geen foutmelding, niets. De app werkte gewoon, terwijl de voordeur al die tijd op een kier stond. Dat is het gevaarlijke aan AI-code: een lek schreeuwt niet om aandacht.
En SQL-injection is maar één voorbeeld. Denk ook aan API-sleutels die zichtbaar in de code staan, formulieren zonder beveiliging tegen misbruik, of een inlogsysteem dat wachtwoorden onversleuteld opslaat. Allemaal dingen die de AI 'werkend' oplevert, maar niet veilig.
Wat een lek jou als MKB'er kost
Bij Bob Starr ging het om een hobbysite. Bij jou gaat het al snel om klantnamen, e-mailadressen, offerteaanvragen of betaalgegevens. En dan zit je meteen in het domein van de AVG. Lekt die data, dan ben je verplicht dat te melden bij de Autoriteit Persoonsgegevens, en in ernstige gevallen ook bij de getroffen klanten zelf.
De directe schade is een mogelijke boete, maar de echte klap is vertrouwen. Een lokale ondernemer in de Nederlandse MKB-realiteit leeft van zijn reputatie. Eén bericht dat klantgegevens op straat liggen, en je bent maanden bezig om dat recht te zetten. Dat weegt zwaarder dan de paar uur die je bespaarde door snel zelf te bouwen.
Het vervelende is dat je vooraf niet eens weet dat je risico loopt, want je kunt de code niet beoordelen. Je vertrouwt blind op een tool die geoptimaliseerd is op resultaat, niet op zorgvuldigheid. Dat is een prima deal voor een schets, maar een slechte deal voor alles wat je klanten raakt.
Zo bouw je wél veilig met AI
Je hoeft vibe coding niet af te zweren, je moet het alleen volwassen aanpakken. Begin met de AI expliciet om beveiliging te vragen. Voeg aan je opdracht toe: 'controleer alle invoer, voorkom SQL-injection en sla geen wachtwoorden onversleuteld op'. Modellen doen dat prima, maar alleen als je het vraagt. Doe je dat niet, dan kiezen ze voor de snelste route.
Laat vervolgens de code controleren voordat hij live gaat. Dat kan met een tweede AI-pass die specifiek naar kwetsbaarheden zoekt, of beter nog: door iemand die de code écht kan lezen. Houd test en echt gescheiden, gebruik nooit echte klantgegevens om iets uit te proberen, en zet API-sleutels of wachtwoorden nooit los in de code.
En wees eerlijk over de grens van je eigen kennis. Een interne tool voor jezelf? Bouw lekker zelf. Een klantportaal, een webshop of iets met betalingen? Dan is een paar uur van een professional goedkoper dan een datalek. Voor dat soort zaken laat ik liever een maatwerk website bouwen die van begin af aan klopt, dan dat ik achteraf een lek moet dichten.
Wat dit betekent voor jou
Mijn take: vibe coding is een van de beste dingen die het MKB is overkomen. Je maakt in een middag wat vroeger weken kostte, en dat verlaagt de drempel om dingen gewoon te proberen. Daar ben ik groot voorstander van. Maar het verhaal van Bob Starr is een nuchtere herinnering dat 'het werkt' en 'het is veilig' twee verschillende dingen zijn. De AI levert het eerste, niet automatisch het tweede.
Gebruik deze tools dus volop voor prototypes, interne hulpjes en schetsen. Maar zodra er klantdata in zit of de app openbaar online staat, behandel je het als serieus werk: vraag om beveiliging, laat het controleren, en haal er een vakman bij als de inzet hoog is. Sneller bouwen is mooi. Sneller én veilig bouwen is wat je klanten van je verwachten.
Werkt deze AI-ontwikkeling door in jouw bedrijf? maatwerk website bouwen.
Wat is vibe coding precies?
Vibe coding is software bouwen door in gewone taal te beschrijven wat je wilt, waarna een AI-tool zoals Cursor of Replit de code schrijft. Je hoeft zelf niet te kunnen programmeren. Dat maakt het snel en toegankelijk, maar je levert wel inzicht in en controle over de code in.
Is een app die met AI is gebouwd veilig?
Niet vanzelf. De AI optimaliseert op een werkend resultaat, niet op beveiliging. Lekken zoals SQL-injection of zichtbare API-sleutels worden vaak ingebouwd zonder dat je het merkt. Veilig wordt het pas als je expliciet om beveiliging vraagt en de code laat controleren voordat hij live gaat.
Wat is SQL-injection in gewone taal?
Het is een lek waarbij een invoerveld op je site stiekem commando's naar je database doorlaat. In plaats van een naam typt een aanvaller een instructie, en de database voert die uit. Zo kan iemand gegevens uitlezen, aanpassen of verwijderen die hij nooit had mogen zien.
Mag ik met de AVG zomaar een AI-app met klantgegevens live zetten?
Zodra je persoonsgegevens verwerkt, gelden de regels van de AVG, ongeacht of je de app zelf of met AI hebt gebouwd. Lekt die data, dan moet je dat melden bij de Autoriteit Persoonsgegevens. Zorg dus dat de beveiliging op orde is voordat er ook maar één klantnaam in komt.
Hoe maak ik mijn vibe-coded app veiliger?
Vraag de AI expliciet om invoer te controleren en geen geheimen in de code te zetten, gebruik geen echte klantdata in tests, en laat de code reviewen voordat hij online gaat. Voor alles met klantgegevens of betalingen is een professionele controle de moeite waard.
Wanneer kan ik beter een professional inschakelen?
Voor interne tools en prototypes is zelf bouwen prima. Maar zodra het gaat om een klantportaal, webshop, betalingen of openbare site met persoonsgegevens, is een paar uur van een vakman goedkoper dan de schade van een datalek.
Grip op AI, zonder de hype
Ontvang de gratis MKB AI Quickstart-gids plus mijn nuchtere AI-updates. Uitschrijven kan altijd met 1 klik.