TL;DR<\/h2>\n\n\n\n
Vibe coding kan geschikt zijn voor prototypes die met synthetische data en beschermde credentials worden getest. Voor persoonsgegevens van echte klanten is het pas klaar als een engineer access control, secrets, databaserechten, invoerverwerking en dependencies in de echte deployment heeft gecontroleerd. In GitHub-projecten vonden Fu e.a. zwakke plekken in 29,5% van de AI-gegenereerde Python-fragmenten en 24,2% van de JavaScript-fragmenten (arXiv 2310.02059).<\/p>\n\n\n\n
- \n
- Blokkeer de lancering bij elke bevestigde bevinding die gevoelige data, bevoorrechte credentials of een uitbuitbaar aanvalspad blootlegt; rangschik de rest op uitbuitbaarheid, blootstelling, gevoeligheid van de data en bedrijfsimpact.<\/li>\n\n\n\n
- De zelfchecks hieronder tonen waarschuwingssignalen zonder code te lezen; een engineer bevestigt ze v\u00f3\u00f3r elk releasebesluit.<\/li>\n\n\n\n
- E\u00e9n bevestigd blokkerend risico is genoeg om de release te stoppen.<\/li>\n<\/ul>\n\n\n\n
Is vibe coding veilig?<\/strong><\/h2>\n\n\n\n
Een vibe-coded prototype kan geschikt zijn voor gecontroleerde tests door u en een paar testers, met synthetische data en beschermde credentials. V\u00f3\u00f3r gebruik door klanten moet iemand anders dan de tool die de code schreef de echte deployment, access control, diensten van derden en dataverwerking beoordelen.<\/p>\n\n\n\n
De voorwaarde weegt zwaarder dan de tool, omdat code die werkt niet vanzelf veilige code is. Toen Fu e.a. 733 AI-gegenereerde codefragmenten uit GitHub-projecten onderzochten, vonden ze zwakke plekken in 29,5% van de Python-fragmenten en 24,2% van de JavaScript-fragmenten, verdeeld over 43 categorie\u00ebn in de Common Weakness Enumeration (arXiv 2310.02059<\/a>). De Common Weakness Enumeration (CWE) is de standaardcatalogus van MITRE voor soorten zwakke plekken in software, en al die fragmenten waren al in een gepubliceerd project terechtgekomen.<\/p>\n\n\n\n
Het onderzoek gaat over codefragmenten, niet over de beveiliging of het aantal datalekken van complete vibe-coded apps. Wat het wel laat zien, is dat “het werkt” en “het is veilig” twee aparte tests zijn, en dat een vibe-coded app die alleen is gedemonstreerd, alleen de eerste heeft doorstaan.<\/p>\n\n\n\n
Ook door mensen geschreven code zakt voor securitytests, dus het verschil zit niet in de maker. Het zit in de review: AI-gegenereerde code kan net als andere code worden beoordeeld en getest, maar in veel vibe coding-workflows leest niemand haar regel voor regel, en daardoor gaan fouten live die een reviewer had gevonden. Het risico hangt dus af van geverifieerde controles, niet alleen van wie de code schreef.<\/p>\n\n\n\n
In de praktijk ligt de grens voor de release bij de vraag of uw product echte klantgegevens, betalingen of gevoelige processen gaat verwerken. AVG-verplichtingen kunnen al eerder ontstaan, ook tijdens ontwikkeling en testen als daarbij echte persoonsgegevens worden verwerkt. Gebruik synthetische data voor prototypes en controleer access control, bewaartermijnen en eventuele doorgiften buiten de EU voordat u klanten toelaat.<\/p>\n\n\n\n
Waarom vibe-coded apps breken zodra echte gebruikers komen<\/strong><\/h2>\n\n\n\n
Vibe-coded apps breken vaak bij de lancering omdat prompts meestal functies beschrijven, geen beperkingen. “Klanten zien hun bestellingen” is een functie; “en nooit de bestellingen van anderen” is een beperking, en zolang niemand die specificeert en test, kunt u er niet van uitgaan dat de AI hem heeft gebouwd.<\/p>\n\n\n\n
Een demo verbergt dat gat, omdat \u00e9\u00e9n gebruiker met testdata geen records van anderen kan zien als die er niet zijn. Productie haalt die dekking weg: er komen veel gebruikers bij die van elkaar gescheiden moeten blijven, persoonsgegevens onder de AVG en geautomatiseerde scanners die in openbare apps en code-repositories zoeken naar API keys en open databases.<\/p>\n\n\n\n
Regels uit uw eigen sector ontbreken om dezelfde reden. Een zorg-, finance- of HR-product moet vaak vastleggen wie welk dossier opende, data na een vaste bewaartermijn verwijderen, of aan AVG-regels voldoen voordat persoonsgegevens buiten de EU worden doorgegeven, en een AI-tool kan geen verplichtingen toepassen die de prompt nooit noemt.<\/p>\n\n\n\n
Problemen oplossen met nieuwe prompts kan het gat juist groter maken. In een peer-reviewed experiment lieten Shukla, Joshi en Syed een AI-model 400 codevoorbeelden ronde na ronde “verbeteren”, en na vijf rondes waren de kritieke kwetsbaarheden met 37,6% gestegen (IEEE-ISTAS 2025, arXiv 2506.11022<\/a>). Het mechanisme is hetzelfde als bij de lancering: elke ronde lost op waar om werd gevraagd en kan ongemerkt een controle verwijderen die niemand noemde. Behandel daarom elke geprompte wijziging aan login, betalingen of gebruikersdata als een nieuwe release die een securitycheck nodig heeft.<\/p>\n\n\n\n
![\"vibe-coding-beveiligingsrisicos-demo-vs-productie\"](\"https:\/\/sunbytes.io\/wp-content\/uploads\/2026\/10\/sunbytes-vibe-coding-beveiligingsrisicos-demo-vs-productie.webp\" "\\"Figuur")
<\/figure>\n\n\n\nFiguur 1. Dezelfde vibe-coded app, v\u00f3\u00f3r en na echte gebruikers<\/em><\/p>\n\n\n\n
Zeven vibe coding security-risico’s die het zwaarst wegen<\/strong><\/h2>\n\n\n\n
De zeven risico’s hieronder dekken het meeste van wat misgaat wanneer een vibe-coded app echte gebruikers krijgt, en elk risico hoort bij een onderdeel van de OWASP Top 10:2025<\/a>, de meest gebruikte lijst van securityrisico’s in webapplicaties, of bij een benoemd CWE-type. Elk onderdeel legt uit hoe het risico ontstaat en eindigt met een zelfcheck die u zonder code te lezen uitvoert. Deze checks tonen waarschuwingssignalen, geen bevestigde kwetsbaarheden, dus voer ze alleen uit met testaccounts en synthetische data, in systemen die van u zijn of die u mag beoordelen. V\u00f3\u00f3r elk releasebesluit controleert een engineer de onderliggende API-responses, rechten en databaseconfiguratie.<\/p>\n\n\n\n
![\"vibe-coding-beveiligingsrisicos-zeven-risicos\"](\"https:\/\/sunbytes.io\/wp-content\/uploads\/2026\/10\/sunbytes-vibe-coding-beveiligingsrisicos-zeven-risicos.webp\" "\\"Figuur")
<\/figure>\n\n\n\nFiguur 2. Zeven risico’s in vibe-coded apps en wanneer ze de lancering blokkeren<\/em><\/p>\n\n\n\n
1. Gebruikers zien data van andere gebruikers<\/strong><\/h3>\n\n\n\n
Broken access control betekent dat een gebruiker data van iemand anders kan lezen of wijzigen. Access control is het geheel aan regels dat bepaalt wie wat mag zien of wijzigen. OWASP zet broken access control op A01, het grootste risico in de OWASP Top 10:2025. Een veelvoorkomende vorm is een insecure direct object reference (IDOR): de app vertrouwt het record-ID in een verzoek en geeft elk record terug waar dat ID naar wijst.<\/p>\n\n\n\n
In vibe-coded apps valt dat makkelijk weg, omdat de interface de data van andere klanten keurig kan verbergen terwijl de server die data nog steeds teruggeeft aan iedereen die er rechtstreeks om vraagt. Een check moet daarom de server testen, niet het scherm.<\/p>\n\n\n\n
Zelfcheck:<\/strong> maak twee testaccounts aan, log in als gebruiker B en open een factuur of profielpagina van gebruiker A door het ID in de adresbalk te veranderen. Ziet gebruiker B de data van gebruiker A, dan geeft de server records terug die hij zou moeten weigeren, en wacht er dus een datalek op de eerste nieuwsgierige klant.<\/p>\n\n\n\n
![\"-vibe-coding-beveiligingsrisicos-id-check\"](\"https:\/\/sunbytes.io\/wp-content\/uploads\/2026\/10\/sunbytes-vibe-coding-beveiligingsrisicos-id-check.webp\" "\\"Figuur")
<\/figure>\n\n\n\nFiguur 3. Test access control in drie stappen<\/em><\/p>\n\n\n\n
2. Logincontroles die alleen in de browser draaien<\/strong><\/h3>\n\n\n\n
Authenticatie stelt vast wie een gebruiker is, terwijl autorisatie bepaalt waar die gebruiker toegang toe heeft. Geen van beide beslissingen mag alleen op controles in de browser steunen, omdat gebruikers kunnen aanpassen wat in hun eigen browser draait. De backend moet de sessie en de rechten controleren voordat hij beschermde data teruggeeft of een actie uitvoert. Ontbrekende autorisatie op de server valt onder OWASP A01:2025 Broken Access Control; zwakke plekken in login en sessies vallen onder A07:2025 Authentication Failures.<\/p>\n\n\n\n
Zelfcheck:<\/strong> open een pagina die een betaald abonnement of een adminrol vereist in een priv\u00e9venster, zonder in te loggen. Verschijnt beschermde data, ook kort voordat de pagina zich verbergt, dan is dat een waarschuwingssignaal. Het bewijs zit echter een laag dieper: een engineer roept de beschermde API aan zonder geldige sessie of met een lagere rol, en kijkt of er data of acties terugkomen. Is dat zo, dan zijn betaalde functies gratis en adminfuncties openbaar.<\/p>\n\n\n\n
3. API keys en secrets in de frontendcode<\/strong><\/h3>\n\n\n\n
Een API key werkt als een wachtwoord voor een betaalde dienst, tenzij het een publishable key is die bedoeld is om in frontendcode te staan en aan de kant van de aanbieder wordt begrensd. Het risico zit bij geheime keys: roept een vibe-coded app een externe dienst rechtstreeks vanuit de browser aan, dan reist de key met de pagina mee, en elke bezoeker kan hem lezen omdat de browser die code downloadt. MITRE noemt dit CWE-798, use of hard-coded credentials. Hoe keys lekken en hoe u ze vervangt, leest u in gelekte API keys<\/strong>.<\/p>\n\n\n\n
Zelfcheck:<\/strong> open uw app, klik met de rechtermuisknop, kies “Paginabron weergeven” en zoek naar “key”, “secret” en “token”. Een lange, willekeurig ogende waarde is een waarschuwingssignaal, maar alleen een engineer kan vaststellen of het een publishable key is of een secret, zoals een geheime betaalsleutel of een service-role key van de database. Dat onderscheid telt, omdat met een blootgesteld secret kan iedereen uw rekening laten oplopen of de data erachter lezen.<\/p>\n\n\n\n
4. Een database met uitgeschakelde toegangsregels<\/strong><\/h3>\n\n\n\n
Veel vibe-coded apps gebruiken een gehoste database waarmee de browser rechtstreeks praat. Dat ontwerp steunt op toegangsregels op rijniveau, die in de database bepalen welke rijen elke gebruiker mag lezen of wijzigen, samen met de databaserechten van elke rol. Een ontbrekende policy of een te ruim recht voor een rol kan records blootstellen via de verbindingsgegevens die elke bezoeker ontvangt, afhankelijk van de feitelijke rechten en datastromen. OWASP rekent dit tot A02:2025 Security Misconfiguration.<\/p>\n\n\n\n
Zelfcheck:<\/strong> vraag uw bouwer schriftelijk welke tabellen voor de client openstaan en of de toegangsregels op rijniveau op elk ervan aanstaan. Omdat regels en rechten samenwerken, vraagt u ook welke databaserechten de publieke en ingelogde rollen hebben, en of beide met twee accounts zijn getest. Laat daarna een engineer met aparte testaccounts verifi\u00ebren welke handelingen zijn toegestaan en geweigerd, omdat wat een ontbrekende policy blootstelt afhangt van de rechten erachter.<\/p>\n\n\n\n
5. Invoer die nooit wordt gecontroleerd<\/strong><\/h3>\n\n\n\n
Invoervalidatie betekent dat de server elke waarde die een gebruiker verstuurt controleert voordat hij die gebruikt. Zonder die controle kan een formulierveld opdrachten bevatten die de database, of de browser van een andere gebruiker, uitvoert. OWASP noemt dit A05:2025 Injection, waaronder SQL-injectie en cross-site scripting (XSS), en cross-site scripting hoorde bij de drie meest voorkomende zwakke plekken in het GitHub-onderzoek van Fu e.a.<\/p>\n\n\n\n
Zelfcheck:<\/strong> typ <b>test<\/b> in een naam- of reactieveld en sla het op. Verschijnt het woord elders in de app vetgedrukt, dan verwerkt de app gebruikersinvoer mogelijk als code: een waarschuwingssignaal, geen bewijs van een uitbuitbare fout. Een engineer bevestigt of scriptuitvoering of injectie mogelijk is; is dat zo, dan kan een aanvaller handelen binnen de sessies van andere gebruikers of data bereiken die hij nooit had mogen zien.<\/p>\n\n\n\n
6. Pakketten die de AI verzon of die niemand controleerde<\/strong><\/h3>\n\n\n\n
Een pakket, ook wel dependency genoemd, is externe code die uw app downloadt om te kunnen draaien. AI-tools voegen pakketten makkelijk toe, en sommige suggesties noemen pakketten die niet bestaan. Dat geeft aanvallers een opening: zij registreren die verzonnen namen en vullen ze met kwaadaardige code, een techniek die slopsquatting heet. OWASP noemt het bredere risico A03:2025 Software Supply Chain Failures.<\/p>\n\n\n\n
Zelfcheck:<\/strong> vraag uw bouwer om de lijst met pakketten die de app gebruikt en wie elk pakket koos. Een pakket dat niemand kan verklaren, of een pakket met heel weinig downloads, verdient een tweede blik, omdat het na installatie met volledige toegang tot uw app en uw data draait, ook al schreef niemand aan uw kant die code.<\/p>\n\n\n\n
7. Geen logging, rate limiting of foutafhandeling<\/strong><\/h3>\n\n\n\n
Logging legt vast wat er in uw app gebeurde, rate limiting begrenst hoeveel verzoeken \u00e9\u00e9n gebruiker of bot kan sturen, en foutafhandeling bepaalt wat een gebruiker ziet als iets misgaat. Geen van deze controles is zichtbaar in een demo, dus niemand vraagt de AI erom. OWASP beschrijft de gaten als A09:2025 Security Logging and Alerting Failures en A10:2025 Mishandling of Exceptional Conditions.<\/p>\n\n\n\n
Zelfcheck:<\/strong> vraag uw team wat er gisteren in de app gebeurde. Kan niemand dat uit een log beantwoorden, en accepteert de loginpagina honderden foute wachtwoorden zonder te vertragen, dan ontbreken beide controles. Daardoor ziet u een aanval niet terwijl die loopt, en na een incident weet u niet welke data is geraakt.<\/p>\n\n\n\n