---
title: "Vibe-coded apps lekken bedrijfsdata — waarom een technical assessment vóór livegang cruciaal is | Coding Agency"
description: "Onderzoek van WIRED beschrijft duizenden AI-gegenereerde apps die medische gegevens, klantgesprekken en go-to-market presentaties zonder enige beveiliging op het open web zetten. Wij zien het patroon terug in onze technical assessments — en herstellen het voordat het in productie komt."
url: https://coding.agency/kennisbank/vibe-coded-apps-lekken-bedrijfsdata
source: Coding Agency (https://coding.agency)
language: nl
---

AI  9 min leestijd  

#  Vibe-coded apps lekken bedrijfsdata — waarom een technical assessment vóór livegang cruciaal is. 

Onderzoek van WIRED beschrijft duizenden AI-gegenereerde apps die medische gegevens, klantgesprekken en go-to-market presentaties zonder enige beveiliging op het open web zetten. Wij zien het patroon terug in onze technical assessments — en herstellen het voordat het in productie komt.

 [ Jasper Koers ](https://coding.agency/over/jasper-koers) · 9 mei 2026 

 ##  In het kort 

- WIRED beschrijft 5.000+ vibe-coded apps zonder noemenswaardige beveiliging, ~2.000 daarvan tonen privé- of bedrijfsdata
- 40% van de gevonden apps lekt gevoelige data — van patiëntgegevens tot strategie-presentaties
- AI-coding tools voegen geen security toe als je er niet om vraagt — gebruikers zonder dev-achtergrond weten niet wát ze moeten vragen
- Het echte risico zit niet in het model maar in het ontbreken van een development-cyclus rond de gegenereerde app
- Een technical assessment vóór livegang vangt deze patronen op voordat ze in productie staan

## Wat WIRED ontdekte: 5.000 lekkende apps in een paar zoekopdrachten

WIRED publiceerde recent een onderzoek dat de schaal van het probleem zichtbaar maakt: [duizenden vibe-coded apps zetten bedrijfs- en persoonsdata op het open web](https://www.wired.com/story/thousands-of-vibe-coded-apps-expose-corporate-and-personal-data-on-the-open-web/). Het cybersecurity-bedrijf RedAccess analyseerde apps die zijn gebouwd met de AI-tools Lovable, Replit, Base44 en Netlify — en vond meer dan 5.000 applicaties die met een eenvoudige browser-URL benaderbaar waren, zonder authenticatie of met alleen een symbolische barrière.

Onderzoeker Dor Zvi en zijn team gebruikten Google- en Bing-zoekopdrachten op de subdomeinen van die AI-leveranciers om het areaal in kaart te brengen. Bij circa 40 procent van de gevonden apps lijken er gevoelige gegevens uit te lekken: medische informatie, financiële data, presentaties met bedrijfsstrategie, en complete logs van klantgesprekken met chatbots — inclusief volledige namen en contactgegevens.

> "Dit is een van de grootste momenten ooit waarop mensen bedrijfs- of andere gevoelige informatie aan iedereen ter wereld blootstellen." — Dor Zvi, RedAccess, geciteerd door [WIRED](https://www.wired.com/story/thousands-of-vibe-coded-apps-expose-corporate-and-personal-data-on-the-open-web/)

Bij een aantal Lovable-apps werden zelfs phishing-pagina's aangetroffen die merken als Bank of America, Costco, FedEx, Trader Joe's en McDonald's nabootsten, gehost op het Lovable-subdomein. Een tweede onafhankelijke onderzoeker, Joel Margolis, bevestigde tegenover WIRED dat hij dit type blootstelling vaker tegenkomt — onder andere recent bij een AI-speelgoed dat 50.000 kindergesprekken op een onbeveiligde website had staan.

## Wat er werkelijk lekt

De screenshots die RedAccess deelde en die WIRED gedeeltelijk verifieerde, zijn niet abstract. Ze tonen onder meer:

- **Werkroosters van een ziekenhuis** met persoonlijk identificeerbare informatie van artsen.
- **Gedetailleerde advertentie-inkoopgegevens** van een bedrijf.
- **Een go-to-market strategie-presentatie** die op het open web stond.
- **Volledige chatlogs** van een retailer met klanten — inclusief volledige namen en contactgegevens.
- **Vrachtregistraties** van een logistieke partij.
- **Sales- en financiële records** van diverse bedrijven.

In een aantal gevallen bleek Zvi zelfs administratieve rechten te kunnen krijgen op deze applicaties — inclusief het kunnen verwijderen van andere beheerders. Dat is geen lek, dat is overhandiging van de sleutels.

## Waarom het zo vaak fout gaat

De reactie van de leveranciers — Replit, Lovable en Base44 — laat zich samenvatten als: het is de verantwoordelijkheid van de gebruiker om de juiste privacy-instellingen te kiezen. Technisch klopt dat: alle drie de platformen bieden controles om apps privé te zetten of toegang te beperken. Maar dat raakt precies de kern van het probleem.

Margolis verwoordt het in WIRED scherp: "Iemand van een marketingteam wil een website maken. Ze zijn geen engineer en hebben weinig tot geen security-achtergrond. AI-coding tools doen wat je vraagt. En tenzij je vraagt om het veilig te doen, gaan ze daar niet uit zichzelf moeite voor doen."

De vergelijking die Zvi maakt is treffend: dit lijkt op de jarenlange epidemie van openstaande Amazon S3-buckets — bedrijven van Verizon tot WWE die per ongeluk grote hoeveelheden data exposeerden door verkeerde configuratie. De cybersecurity-industrie wees toen mede naar Amazon vanwege verwarrende standaardinstellingen. Dezelfde dynamiek herhaalt zich nu bij AI-coding tools.

> "Iedereen in je bedrijf kan op elk moment een app genereren. Die gaat niet door een development-cyclus, niet door een security-check. Mensen zetten 'm gewoon in productie zonder iemand te vragen. En dat doen ze ook." — Dor Zvi in [WIRED](https://www.wired.com/story/thousands-of-vibe-coded-apps-expose-corporate-and-personal-data-on-the-open-web/)

## Het patroon dat wij zien bij technical assessments

Bij Coding Agency krijgen we regelmatig opdrachtgevers binnen die in een week een MVP hebben laten vibe-coden — door een marketingcollega, een product manager, of een externe consultant met "een vlotte AI-workflow". Voor sommige van die opdrachtgevers voeren we vóór de livegang een [technical assessment op een vibe-coded applicatie](https://coding.agency/vibe-coding/technical-assessment) uit. Wat we daar tegenkomen, leest als de hitlist uit het WIRED-artikel:

- **Geen of triviale authenticatie:** dashboards die voor iedereen met de URL toegankelijk zijn, of "login" die elk e-mailadres accepteert zonder verificatie.
- **Ontbrekende autorisatie:** ingelogde gebruikers die elkaars data kunnen zien of bewerken doordat row-level security niet is geconfigureerd.
- **Secrets in de frontend:** API-sleutels, database-credentials of provider-tokens die in de gegenereerde JavaScript te lezen zijn.
- **Geen input-validatie of rate-limiting:** formulieren waar je SQL-achtige strings doorheen krijgt of waarmee je in een paar minuten de hele database kunt leegtrekken.
- **Onbedoelde publieke endpoints:** admin-functies die niet achter een check zitten omdat het model "het werkende voorbeeld" heeft gegenereerd zonder de bewaking eromheen.
- **Logs en chatgeschiedenissen die niet voor publiek bedoeld zijn,** maar wel via een onbeschermde URL beschikbaar zijn.

Dit zijn geen exotische bevindingen — het is wat er standaard ontbreekt zodra niemand expliciet om security heeft gevraagd. En het is exact het patroon dat WIRED beschrijft op duizenden externe apps.

## Het echte probleem: geen development-cyclus

De fundamentele observatie van WIRED — en die wij delen — is dat het probleem niet primair bij het model zit. Het zit in het feit dat deze applicaties buiten elke gebruikelijke ontwikkelcyclus om in productie komen. Geen code review, geen security-check, geen acceptatietest, geen formele oplevering. Iemand demoot een werkende app in een meeting, vindt 'm goed genoeg en deelt de URL met klanten.

Dat is iets om voorzichtig mee te zijn. Niet alleen omdat het kan misgaan — maar omdat het voorspelbaar misgaat. Een collega die "even iets bouwt" met Lovable of Replit en het direct doorzet naar productie, neemt een risico waarvan hij de omvang niet kan inschatten. De AVG-boete bij een datalek met patiëntgegevens of klantgesprekken zit niet in een paar duizend euro. Een go-to-market strategie die per ongeluk leesbaar is voor concurrenten kost geen geld — die kost je markt.

> Een vibe-coded app is geen prototype meer zodra er één klant in zit. En vanaf dat moment gelden alle verplichtingen die ook voor "echte" software gelden — alleen heeft niemand de checks gedaan om te weten of de app daaraan voldoet.

## De juiste volgorde: technical assessment vóór livegang

De stelregel die wij hanteren is simpel: een vibe-coded app mag alle voordelen hebben van snelheid en validatie, maar gaat niet naar productie zonder een controle-stap ertussen. Een technical assessment vóór livegang is geen rem op innovatie — het is wat het verschil maakt tussen een MVP en een datalek.

Wat zo'n assessment bij ons concreet toetst:

- **Authenticatie en autorisatie:** wie kan inloggen, wie ziet wat, kunnen gebruikers buiten hun eigen scope?
- **Data-validatie en input handling:** wat gebeurt er bij rare input, SQL-achtige strings, oversized payloads?
- **Secret management:** staan API-sleutels en credentials op de juiste plek, of in de browser?
- **AVG-conformiteit:** waar staat persoonsdata, hoe lang, wie heeft toegang, is er een verwerkingsregister, is data-export en -verwijdering geregeld?
- **Dependencies en supply chain:** draait de app op gangbare, onderhouden libraries of op exotische pakketten met onduidelijke geschiedenis?
- **Infrastructuur:** staat de app op een subdomein van de AI-provider met onbedoeld publieke routes, of op een eigen omgeving met expliciete security controls?
- **Logging en observability:** kun je überhaupt zien wat er gebeurt als er iets misgaat, of word je pas gebeld door een journalist?

De uitkomst is een rapport met bevindingen op risico-niveau (kritiek, hoog, gemiddeld, laag), elk met een concrete remediatie. Bij kritieke en hoge bevindingen is het advies altijd: oplossen vóór livegang. Bij gemiddelde en lage bevindingen kun je een afweging maken op basis van risk appetite.

## Vibe-coding én volwassen software — het hoeft geen of/of te zijn

Dit is geen pleidooi tegen vibe coding. AI-tools zoals [Lovable](https://coding.agency/vibe-coding/lovable), [Replit](https://coding.agency/vibe-coding/replit) en [Bolt](https://coding.agency/vibe-coding/bolt) zijn echt nuttig — voor snelle prototypes, voor interne experimenten, voor het valideren van een concept met een werkende app in plaats van een mockup. We zien klanten die in een week een idee testen wat anders in een maand specificeren had gekost. Dat is winst.

Wat geen winst is: dezelfde week-één applicatie zonder controle in productie zetten met klantdata erin. De keuze is niet "wel of niet AI gebruiken" — het is "AI plus een development-cyclus" versus "AI zonder development-cyclus". Het verschil tussen die twee verklaart het overgrote deel van de 5.000 apps die RedAccess vond.

Voor opdrachtgevers die hun vibe-coded MVP serieus naar productie willen brengen, hebben we daarvoor een gestructureerd traject — beschreven op onze [Technical Assessment-pagina](https://coding.agency/vibe-coding/technical-assessment). We bekijken de applicatie tegen onze checklist, leveren een rapport, en kunnen de remediatie zelf uitvoeren of begeleiden. Voor producten die echt schalen volgt daarna vaak een [migratie-traject naar een onderhoudbare maatwerk-codebase](https://coding.agency/kennisbank/vibe-coding-risicos-en-mogelijkheden), zodat je niet voor altijd vastzit aan de provider waar je app oorspronkelijk op gegenereerd is.

## Wat te doen als je nu twijfelt

Drie praktische vragen die je deze week kunt stellen, ongeacht of je zelf vibe-codet of alleen het beheert:

1. **Welke vibe-coded applicaties draaien er momenteel binnen mijn organisatie?** Vraag bij collega's na, kijk in factuuroverzichten naar Lovable-, Replit-, Bolt-, v0-, Base44- of Netlify-abonnementen. Bij grotere organisaties is dit zonder uitzondering meer dan men denkt.
2. **Welke daarvan staan al online en bevatten klantdata of bedrijfsgevoelige gegevens?** Een dashboard met klantnamen, een tool met salarisdata, een formulier dat persoonsgegevens verzamelt — alles wat onder de AVG valt of concurrentiegevoelig is.
3. **Is er voor die applicaties een controle uitgevoerd vóór livegang?** Als het antwoord "nee" of "weet ik niet" is, is dat het moment om dat te laten doen — en niet pas wanneer er een datalek-melding aan de Autoriteit Persoonsgegevens nodig blijkt.

De WIRED-onderzoekers vonden 5.000 apps in een paar dagen door simpelweg op de subdomeinen van de AI-providers te zoeken. Dezelfde zoektocht is voor iedereen mogelijk — voor concurrenten, voor journalisten, en voor mensen met minder vriendelijke bedoelingen. Dat is geen reden voor paniek, maar wel voor één concrete actie: zorg dat de apps in jouw organisatie niet in die volgende lichting zitten.

## Onze rol

Wij voeren technical assessments uit op vibe-coded en AI-gegenereerde applicaties — meestal binnen een paar werkdagen, met een rapport dat je intern kunt delen en dat aansluit op de eisen die de AVG, NIS2 en je eigen compliance-kader stellen. Vervolgens helpen we met de remediatie, en waar nodig met een gefaseerde migratie naar een onderhoudbaar maatwerk-platform.

Twijfel je over een applicatie die binnen je organisatie wordt gebruikt of binnenkort live moet? [Vraag een technical assessment aan](https://coding.agency/vibe-coding/technical-assessment) of [plan een vrijblijvend gesprek](https://coding.agency/contact) — dan lopen we de risico-checklist samen door, eerlijk en op basis van wat de applicatie echt doet.

##  Veelgestelde vragen 

 Vibe coding is software bouwen door een AI-tool — Lovable, Replit, Bolt, v0, Base44 — met natuurlijke taal aan te sturen. Je beschrijft wat je wilt, het model genereert code, koppelt een database, deployt op een subdomein van de provider en je hebt binnen minuten een werkende app. Voor prototypes en intern experimenteren is dat krachtig; voor productie-toepassingen met klantdata is het zonder controle vragen om problemen. 

 AI-tools doen wat je vraagt, niet wat je nodig hebt. Als de gebruiker niet expliciet om authenticatie, autorisatieregels, row-level security of input-validatie vraagt, voegt het model dat meestal niet uit zichzelf toe. Dat is geen kwade wil van het model, maar een directe consequentie van hoe deze tools werken: instructie in, output uit. Een ervaren developer kent de standaard-veiligheidsvragen, een marketingmedewerker met een prompt-veld kent ze niet. 

 Een technical assessment is een gestructureerde controle van een (vibe-)gecodeerde applicatie vóór de livegang: authenticatie, autorisatie, data-validatie, secret management, AVG-conformiteit, dependency-risico's en infrastructuur-keuzes. Wij voeren die uit in een paar werkdagen en leveren een rapport met bevindingen op risico-niveau, plus concrete remediatie. De juiste volgorde: assessment vóór livegang, niet erna. 

 De omvang hangt af van de applicatie en het aantal integraties. De meeste vibe-coded MVP's passen binnen een vast pakket dat in 3 tot 5 werkdagen wordt opgeleverd. Op de pagina Technical Assessment vraag je een offerte aan op basis van je platform en architectuur — wij zien meestal binnen één werkdag terug of de scope realistisch is. 

 Gerelateerde expertise — AI-software **Meer weten over ai-software?** Bekijk onze aanpak, werkwijze en referentieprojecten.

 [ Bekijk onze aanpak ](https://coding.agency/expertises/artificial-intelligence) [ Gratis prijsindicatie ](https://coding.agency/prijsindicatie) 

 Onderwerpen [Vibe-coding](https://coding.agency/kennisbank?q=Vibe-coding) [Security](https://coding.agency/kennisbank?q=Security) [Data lek](https://coding.agency/kennisbank?q=Data+lek) [Technical Assessment](https://coding.agency/kennisbank?q=Technical+Assessment) [AVG](https://coding.agency/kennisbank?q=AVG) [Lovable](https://coding.agency/kennisbank?q=Lovable) [Replit](https://coding.agency/kennisbank?q=Replit) 

  ##  Gerelateerde artikelen 

 [ 

 AI### Vibe-coding: mooie mogelijkheden én risico's

Wanneer zijn Lovable, Bolt en Replit briljant en wanneer wordt het riskant?

 Lees artikel 

 ](https://coding.agency/kennisbank/vibe-coding-risicos-en-mogelijkheden) [ 

 AI### AI security: prompt injection en guardrails

Hoe je AI-features veilig bouwt zonder manipulatie of dataverlies.

 Lees artikel 

 ](https://coding.agency/kennisbank/ai-security-en-prompt-injection) [ 

 Juridisch### AVG / GDPR voor webapplicaties

Wat moet je regelen om AVG-compliant te zijn voordat je live gaat?

 Lees artikel 

 ](https://coding.agency/kennisbank/avg-gdpr-webapplicaties) 

##  Hulp nodig? 

Vragen over dit onderwerp? Laten we het erover hebben.

 [ Neem contact op ](https://coding.agency/contact)

---
*Bron: [Coding Agency](https://coding.agency/kennisbank/vibe-coded-apps-lekken-bedrijfsdata)*