Security voor AI-gebouwde apps
Vibe-coded apps staan binnen enkele uren online, maar de basisbeveiliging —blootgestelde secrets, ontbrekende databaseregels, open CORS, missende headers— wordt onderweg overgeslagen. Deze gids legt uit welke fouten AI-gebouwde apps écht raken, hoe je er in 30 seconden op controleert en waar je dieper kunt duiken voor jouw stack.
Wat "vibe coding security" betekent
AI-tools bouwen apps waarin de browser rechtstreeks met je database en services praat. Dat is handig, maar het verplaatst de beveiliging van je code naar je configuratie: wat je beschermt zijn de databaseregels, de headers en welke keys waar staan — niet de mooie code van de interface.
Het probleem is dat die onderdelen standaard niet goed zijn ingesteld, en de AI configureert ze zelden voor je. Het resultaat: apps die er perfect uitzien maar data of keys blootgeven aan iedereen die weet waar hij moet kijken.
De fouten waar AI-gebouwde apps het meest last van hebben
API-keys in de browser: als je een service "koppelt", belandt de key in client-side JavaScript, waar hij voor altijd openbaar is.
Ontbrekende of zwakke databaseregels: zonder goede Row-Level Security (Supabase) of met regels in testmodus (Firebase) kan iedereen je tabellen lezen en beschrijven zonder in te loggen.
Te ruime CORS: een beleid dat elke origin met credentials weerspiegelt, geeft de data van je gebruikers bloot.
Ontbrekende security headers: zonder CSP, HSTS of X-Frame-Options staat je app open voor clickjacking, injectie en downgrade.
Toegankelijke gevoelige bestanden: .env, source maps of back-ups waarmee iedereen je code kan reconstrueren of secrets kan lekken.
Dat de app "er goed uitziet" betekent niet dat hij veilig is
Een knop verstoppen in de interface beschermt niets: de request blijft een openbare URL die iedereen rechtstreeks kan aanroepen. Echte beveiliging zit op de server en in de database, niet in wat de gebruiker ziet. Daarom is controleren van buitenaf —zoals een aanvaller zou doen— de enige manier om te weten wat er werkelijk blootligt.
Hoe je het in 30 seconden controleert
Scanaris scant je gepubliceerde site read-only: het raakt je code nooit aan en verandert niets. Het detecteert deze fouten, rangschikt ze op impact (kritiek eerst) en geeft je voor elke bevinding een kant-en-klare AI-fixprompt die je meteen kunt plakken. Plak je URL en weet het zeker voordat je je app deelt.
Duik dieper voor jouw stack
Next.js
Beveiliging voor je Next.js-app
Supabase
Beveiliging voor je app met Supabase
Firebase
Beveiliging voor je app met Firebase
Vercel
Beveiliging bij het deployen naar Vercel
Lovable
Beveiliging en zichtbaarheid voor je Lovable-app
Bolt
Beveiliging voor je Bolt-app
v0
Beveiliging voor je v0-app
Replit
Beveiliging voor je Replit-app
Cursor
Beveiliging voor de code die je met Cursor schrijft
Belangrijkste beveiligingschecks
Gerelateerde gidsen
Veelgestelde vragen
Is mijn Lovable-, Bolt- of Cursor-app veilig?
Dat kan, maar standaard komt hij meestal online met keys in de frontend, onvolledige databaseregels en zonder security headers. De enige manier om het te weten is je gepubliceerde site controleren: Scanaris doet dat in 30 seconden, read-only.
Is het scannen van mijn site gevaarlijk ervoor?
Nee. Scanaris voert read-only checks uit op informatie die al openbaar is (headers, cookies, certificaten, toegankelijke bestanden). Het wijzigt, verwijdert of injecteert nooit iets. Je zou alleen sites moeten scannen die van jou zijn of die je mag testen.
Moet ik verstand hebben van security om het te gebruiken?
Nee. Elke bevinding komt met een duidelijke uitleg en een kant-en-klare AI-fixprompt, zodat je het kunt oplossen zonder expert te zijn.