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. 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
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
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 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, Replit en 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. 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, 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:
- 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.
- 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.
- 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 of plan een vrijblijvend gesprek — dan lopen we de risico-checklist samen door, eerlijk en op basis van wat de applicatie echt doet.
