De beveiligingsrisico’s van vibe-coded applicaties

Hoe AI-gegenereerde applicaties onbedoeld publiek toegankelijk worden

Vibe coding betekent dat een AI-tool applicatiecode genereert op basis van natuurlijke taal. De aanpak is geschikt voor prototypes en interne hulpmiddelen, maar gegenereerde code moet vóór productie altijd door een deskundige worden beoordeeld.

Applicaties worden vaak publiek toegankelijk door standaardinstellingen van cloudplatforms, openbare preview-omgevingen, verkeerd ingestelde opslag of ontbrekende autorisatie op API-endpoints. Een interface kan gegevens verbergen, terwijl de server of database deze nog steeds zonder controle teruggeeft.

Controleer of productie-, test- en preview-omgevingen afzonderlijk zijn afgeschermd.
Gebruik standaard deny by default voor routes, bestanden, databases en cloudopslag.
Controleer rechtstreeks met een browser en API-client welke gegevens een niet-ingelogde gebruiker kan opvragen.
Behandel zelfstandig gepubliceerde applicaties als mogelijke shadow IT en registreer eigenaar, doel, data en hostinglocatie.

Authenticatie, autorisatie, secrets en persoonsgegevens

Authenticatie

AI-gegenereerde applicaties vertrouwen soms op gegevens die de browser zelf aanlevert, gebruiken zwakke sessies of beschermen alleen de gebruikersinterface. Verifieer identiteit altijd server-side en gebruik goedgekeurde SSO- en MFA-oplossingen.

Controleer sessie-expiratie, tokenvalidatie, logout en wachtwoordherstel.
Test toegang zonder login en met een verlopen, gemanipuleerd of gestolen token.
Gebruik geen zelfgebouwde authenticatie als een goedgekeurde identity provider beschikbaar is.

Autorisatie

Authenticatie bewijst wie iemand is; autorisatie bepaalt wat die persoon mag doen. Test iedere actie en ieder object afzonderlijk. Een gebruiker mag bijvoorbeeld niet alleen omdat hij een geldig account heeft de gegevens van een andere klant kunnen opvragen.

Controleer rollen en rechten op de server én in de database.
Test horizontale toegang: gebruiker A mag geen records van gebruiker B lezen of wijzigen.
Test verticale toegang: een gewone gebruiker mag geen beheerfuncties uitvoeren.
Log mislukte autorisatiepogingen en beoordeel deze periodiek.

Secrets en persoonsgegevens

Plaats nooit wachtwoorden, API-sleutels, tokens of persoonsgegevens in prompts, broncode, browserbundles, testdata, logs of openbare repositories. AI-tools en agenten mogen alleen toegang krijgen tot de gegevens die noodzakelijk zijn.

Gebruik een beheerde secret vault en korte, roterende credentials.
Voer secret-scanning uit op broncode, commits, configuratiebestanden en notebooks.
Verwijder gelekte secrets direct, roteer ze en onderzoek mogelijk misbruik.
Minimaliseer persoonsgegevens en gebruik geanonimiseerde testdata.
Leg vast welke AI-tool data verwerkt en of invoer voor modeltraining wordt gebruikt.

Dependencies, prompt injection en onveilige standaardconfiguraties

AI-modellen kunnen kwetsbare, verouderde of niet-bestaande packages voorstellen. Controleer iedere dependency op herkomst, onderhoud, versies en bekende kwetsbaarheden voordat deze wordt geïnstalleerd. Aanvallers kunnen bovendien bewust een vergelijkbaar pakket registreren om installatie door gegenereerde code uit te lokken.

Gebruik een goedgekeurde package registry en lockfiles.
Voer dependency-scanning uit in iedere build.
Laat de pipeline falen bij kritieke kwetsbaarheden of onbekende packages.
Verwijder ongebruikte dependencies en beperk runtime-rechten.

Prompt injection ontstaat wanneer schadelijke instructies in webpagina’s, tickets, code, logs of documenten een AI-agent beïnvloeden. Behandel alle externe inhoud als onbetrouwbaar en voorkom dat een agent zelfstandig secrets leest, code uitvoert of productie wijzigt.

Gebruik read-only toegang voor verkennende taken.
Geef agents geen permanente productiecredentials.
Vraag expliciete bevestiging vóór netwerkacties, schrijfacties, deployments of shell-opdrachten.
Controleer iedere gegenereerde wijziging en toolactie met een menselijke reviewer.

Verwijder onveilige standaardconfiguraties vóór publicatie: debugmodus, standaardaccounts, uitgebreide foutmeldingen, openbare databases, brede CORS-regels, onbeveiligde adminroutes en standaard cloudrechten.

Praktische pre-production securitychecklist

Gebruik deze checklist vóór iedere productiepublicatie. Documenteer afwijkingen en laat een bevoegde eigenaar risico’s formeel accepteren.

Is de applicatie geregistreerd met een eigenaar, doel, dataclassificatie en hostinglocatie?
Zijn alleen goedgekeurde AI-tools, repositories en deploymentplatforms gebruikt?
Is alle broncode opgeslagen in versiebeheer met branch protection en review?
Zijn secrets verwijderd uit prompts, code, commits, logs, builds en client-side bestanden?
Zijn SSO, MFA, sessiebeheer en wachtwoordherstel getest?
Zijn autorisaties server-side afgedwongen en getest met positieve en negatieve scenario’s?
Zijn inputvalidatie, parameterized queries, veilige output encoding en CSRF-bescherming toegepast?
Zijn dependencies gecontroleerd, vastgezet en automatisch gescand?
Zijn SAST, secret-scanning, DAST en kwetsbaarheidsscans uitgevoerd?
Zijn persoonsgegevens geminimaliseerd, versleuteld en verwijderd uit testdata?
Zijn cloudopslag, databases, API’s, preview-omgevingen en adminroutes standaard afgeschermd?
Zijn back-ups getest en is herstel mogelijk zonder afhankelijkheid van de AI-tool?
Zijn functionele tests, misbruikscenario’s, autorisatietests en privacychecks gedocumenteerd?
Heeft een menselijke reviewer de architectuur, code, risico’s en deployment goedgekeurd?

Monitoring, incidentrespons en periodieke herbeoordeling

Beveiliging eindigt niet bij de deployment. Verzamel centrale logs voor authenticatie, autorisatie, wijzigingen, foutmeldingen, adminacties en afwijkend dataverkeer. Log geen wachtwoorden, tokens of onnodige persoonsgegevens.

Stel meldingen in voor veelvuldige loginpogingen, privilege-escalatie, massale exports en wijzigingen aan secrets.
Controleer regelmatig openbare endpoints, cloudrechten, DNS-records en opslagconfiguratie.
Gebruik back-ups, dependency alerts en een bijgehouden inventaris van applicaties en datastromen.

Bij een vermoeden van blootstelling: beperk direct de toegang, roteer secrets, bewaar relevante logs, identificeer geraakte systemen en informeer de verantwoordelijke security- en privacycontacten. Beoordeel vervolgens of melding aan klanten, toezichthouders of andere partijen nodig is.

Plan minimaal elk kwartaal en na grote wijzigingen een herbeoordeling. Herhaal deze controle ook wanneer de AI-tool, dependencyset, hostingomgeving, dataverwerking of autorisatiestructuur verandert. De menselijke eigenaar blijft verantwoordelijk voor risicoacceptatie, onderhoud, incidenten en het tijdig buiten gebruik stellen van de applicatie.