AI Security Audit Skill - check je vibe-coded app voordat je publiceert

AI helpt je sneller bouwen dan ooit. Je laat Claude Code een dashboard maken, Codex een API-route verbeteren, Gemini meedenken over UX en ChatGPT een Supabase-policy uitleggen. Dat is precies waarom vibe-coded apps zo aantrekkelijk zijn: je komt snel van idee naar demo. De keerzijde is dat security vaak impliciet blijft. De app werkt, maar niemand heeft rustig gecontroleerd of service keys lekken, muterende routes auth checken, RLS echt aan staat of de publieke URL gevoelige paden weggeeft.

Een klassieke pentest is voor veel kleine teams te zwaar als eerste stap. Tegelijk is "vraag AI of mijn app veilig is" veel te los. Je krijgt dan meestal een lijst met algemene adviezen, maar geen auditroute die je elke release opnieuw kunt uitvoeren. De KREATE AI Security Audit Skill zit tussen die twee uitersten. Hij maakt van security geen vaag gevoel, maar een herhaalbare check op codebase en URL.

Belangrijk: deze workflow vervangt geen professionele pentest voor een app met betaalgegevens, medische data, gevoelige klantdata of hoge juridische risico's. Hij helpt je wel om de grootste bouwfouten eerder te vinden, je fix-plan scherper te maken en een menselijke reviewer beter materiaal te geven.

Waarom losse AI-prompts security missen

Veel developers proberen security op te lossen met een losse prompt: "check deze code op kwetsbaarheden". Dat levert soms nuttige opmerkingen op, maar mist structuur. Een LLM ziet alleen de context die jij geeft. Als je geen migrations, middleware, env-config, storage policies en deploy-instellingen meestuurt, kan het model ook niet betrouwbaar zeggen wat daar gebeurt.

Daarom ontstaan drie typische gaten.

De check is te smal. Je laat alleen een API-route beoordelen, terwijl de kwetsbaarheid in middleware, database policy of client-side dataflow zit. Security zit vaak in de verbinding tussen bestanden.

De ernst is onduidelijk. AI noemt tien aandachtspunten, maar rangschikt niet wat eerst moet. Daardoor besteed je tijd aan nette headers terwijl er misschien een service role key in client code staat.

De fix is te algemeen. Je krijgt advies als "valideer input" of "gebruik auth", maar geen concreet plan: welk bestand, welke route, welke check en welke test bewijst dat de fix werkt.

Een goede AI security audit voor apps gebruikt AI dus niet als losse orakelvraag. Je gebruikt AI als assistent binnen een vaste checklist, met bewijs, prioriteit en menselijke review.

Wat de KREATE AI Security Audit Skill oplost

De skill werkt met twee routes. In codebase mode inspecteer je broncode, configuratie, API-routes, server actions, SQL en build-output. In URL mode doe je niet-destructieve externe reconnaissance: headers, cookies, openbare paden, client bundle signalen en basisresponsen. Heb je beide, dan leg je de uitkomsten naast elkaar. Een codebase kan er netjes uitzien terwijl de live URL toch source maps of gevoelige paden toont. Andersom kan een URL weinig prijsgeven terwijl de code wel een RLS-probleem bevat.

De kern is een 45-punts audit verdeeld over zes fasen: secrets, authenticatie, Supabase, server-client grenzen, infrastructuur en injection/data safety. Per check noteer je pass, fail, warn of niet van toepassing. Daarna groepeer je bevindingen op Critical, High, Medium en Low. Dat maakt het verschil tussen "veel security feedback" en een echt fix-plan.

Die structuur is vooral nuttig voor makers die met moderne stacks werken: Next.js, Supabase, Vercel, server actions, API routes en client components. Juist daar gaan vibe-coded apps vaak mis. Een model schrijft snel werkende code, maar kiest niet altijd de juiste grens tussen client en server. Het zet soms te veel vertrouwen in client-side checks. Het maakt demo-endpoints die later blijven staan. De skill dwingt je om die aannames expliciet te controleren.

Wat AI wel en niet mag beoordelen

AI is sterk in patroonherkenning. Het kan verdachte env-namen aanwijzen, ontbrekende auth checks signaleren, ruwe SQL herkennen, security headers opsommen en je helpen een fixprompt te schrijven. Het kan ook uitleggen waarom een Supabase service role key niet in browsercode mag staan of waarom een muterende route zonder sessiecontrole gevaarlijk is.

AI is zwakker in bewijs. Het weet niet automatisch welke code live draait. Het ziet geen productiegeheimen, tenzij jij ze onverantwoord deelt. Het kan een policy verkeerd interpreteren wanneer de databasecontext ontbreekt. Het kan ook false positives geven. Daarom is de juiste houding: gebruik AI om te screenen, ordenen en reparaties voor te bereiden, maar laat gevoelige beslissingen door een mens controleren.

Voor publieke URL checks geldt dezelfde grens. Test alleen systemen waar je toestemming voor hebt. Gebruik geen destructieve payloads, geen brute force, geen DoS en geen poging om data te benaderen die niet van jou is. De KREATE tool is bedoeld als non-destructieve auditlaag voor je eigen app of een geautoriseerde omgeving.

De zes auditfasen

De volledige skill bevat meer detail, maar de publieke route kun je onthouden als zes fasen.

1. Secrets en keys

Zoek naar hardcoded API keys, private keys, database credentials, tokens in build-output en env-bestanden die per ongeluk zijn meegekomen. De fix is meestal direct: verwijderen, roteren, in server-side env plaatsen en git history beoordelen.

2. Authenticatie en autorisatie

Controleer of muterende API routes, server actions en dashboardroutes echt een sessie of role check doen. Let op middleware die alleen pagina's beschermt, maar API-routes overslaat. Controleer ook rate limiting op login, signup en gevoelige formulieren.

3. Supabase en data policies

RLS moet aan staan voor tabellen met gebruikersdata. Policies moeten niet alleen "authenticated" checken, maar meestal ook eigenaarschap via user id afdwingen. Storage buckets verdienen dezelfde aandacht, zeker wanneer uploads openbaar worden geserveerd.

4. Server-client grenzen

Veel AI-gebouwde apps stoppen businessregels in client components omdat dat snel werkt. Vraag bij elke beslissing: mag de browser dit bepalen, of moet de server dit afdwingen? Prijsberekening, rechten, credits, quota en adminacties horen server-side.

5. Infrastructuur en deploy

Check CORS, security headers, debugroutes, error responses, sourcemaps en preview deploys. Een app kan lokaal veilig lijken en in productie toch te veel informatie lekken via headers, stack traces of openbare debugpaden.

6. Injection en data safety

Controleer inputvalidatie, raw SQL, XSS-risico, path traversal, SSRF, file upload regels en mass assignment. Dit zijn de klassieke plekken waar "maak het werkend" code later pijn doet.

Zo run je de audit in 45 minuten

Begin niet met alle bestanden tegelijk. Een snelle maar bruikbare audit heeft volgorde nodig.

1. Maak scope klein. Kies een app, branch, deploy URL en datum. Noteer welke routes en data gevoelig zijn.
2. Verzamel input. Pak relevante API routes, middleware, server actions, Supabase migrations, env-voorbeeldbestanden, next config en deploy notes.
3. Run codebase mode. Laat de skill de 45 checks langs je broncode halen en eis per check pass, fail, warn of niet van toepassing.
4. Run URL mode. Controleer je eigen publieke URL op headers, cookies, source map signalen, gevoelige paden en zichtbare client bundle hints.
5. Prioriteer op risico. Critical en High gaan voor styling, documentatie of nette headers. Fix eerst wat data, auth of secrets raakt.
6. Maak een fixprompt. Zet de topbevindingen om naar een prompt voor Claude Code, Codex of je eigen engineering workflow.
7. Herhaal na de fix. Een audit is pas nuttig als je de gekozen checks opnieuw draait en bewijs noteert.

Publieke prompt om veilig te starten

De volledige KREATE skill bevat meer checks en rapportagevormen. Dit publieke voorbeeld is bewust kort en veilig. Plak geen echte secrets in je prompt. Vervang gevoelige waarden door placeholders.

Je bent mijn security audit assistent voor een geautoriseerde eigen app.

Scope:
- Stack: [Next.js, Supabase, Vercel, anders]
- App URL: [eigen URL]
- Gevoelige data: [type data, geen echte records]
- Codefragmenten: [plak alleen relevante bestanden zonder secrets]

Taak:
1. Controleer secrets, auth, Supabase RLS, server-client grenzen, infrastructuur en injection-risico.
2. Label elke bevinding als Critical, High, Medium of Low.
3. Geef per bevinding bewijs uit de aangeleverde context.
4. Geef een concrete fix per bestand of route.
5. Noem welke aannames nog handmatig moeten worden geverifieerd.

Regels:
- Geen exploitpogingen.
- Geen garanties dat de app veilig is.
- Markeer ontbrekende context als "niet bewezen".
- Vraag om extra bestanden als de scope te smal is.

Losse prompt versus skill workflow

Veelgemaakte fouten

1. Alleen de homepage testen

De homepage zegt weinig over dashboardroutes, uploadroutes en API-acties. Fix: test ook muterende routes, auth flows en de routes waar data wordt aangemaakt of aangepast.

2. Secrets in prompts plakken

Plak nooit echte tokens, service keys, cookies of database credentials in een LLM. Fix: vervang gevoelige waarden door placeholders en roteer alles wat per ongeluk gedeeld is.

3. RLS zien als een Supabase detail

RLS is de grens tussen "ingelogd" en "mag deze rij zien of aanpassen". Fix: beoordeel policies per tabel en test met gebruikers die elkaars data niet mogen lezen.

4. Client checks verwarren met security

Een verborgen knop of disabled input is geen autorisatie. Fix: laat de server elke gevoelige actie controleren, ook als de UI die actie normaal niet toont.

5. Geen hercontrole doen na fixes

Security werk is pas klaar wanneer de fix opnieuw gecontroleerd is. Fix: noteer per bevinding welke test of auditcheck bewijst dat het risico is verlaagd.

Maak security audit een publicatiegewoonte

De beste plek voor deze workflow is niet "ooit voor launch". Gebruik hem als vaste releasecheck. Voor een kleine app kan dat betekenen: elke vrijdag codebase mode op gewijzigde routes, URL mode op staging en een korte lijst met Critical en High bevindingen. Voor een team kan iemand eigenaar worden van auth en data policies, terwijl een andere persoon de live URL en headers controleert.

Maak het klein genoeg om vol te houden. Je hoeft niet elke week een volledige pentest te doen. Je wilt wel voorkomen dat een demo met hardcoded secrets, open debugroute of ontbrekende RLS naar echte gebruikers gaat. Een herhaalbare AI security audit voor apps maakt dat gesprek concreet.

Werk je al met KREATE workflows? Dan sluit deze skill logisch aan op audits zoals website toegankelijkheid audit met AI. Bouw je klantcommunicatie of factuurflows, kijk dan ook naar AI e-mail schrijven en AI factuur maken. Security wordt sterker wanneer elke workflow een eigen controlepunt krijgt.

Veelgestelde vragen

Wat is een AI security audit voor apps?

Dat is een gestructureerde controle waarbij AI helpt om codebase, configuratie en publieke URL langs security checks te halen. De audit geeft risico's, prioriteit en fixrichting, maar bewijst niet dat een app volledig veilig is.

Kan ik hiermee een professionele pentest vervangen?

Nee. Gebruik deze workflow als eerste interne audit, releasecheck of voorbereiding op een review. Voor apps met gevoelige data, betalingen of compliance-risico's blijft professionele security expertise nodig.

Werkt de skill met Claude Code, Codex, Gemini, OpenCode en ChatGPT?

Ja. De workflow is LLM-bruikbaar en kan worden uitgevoerd met Claude Code, Codex, Gemini, OpenCode, ChatGPT en vergelijkbare tools. De kwaliteit hangt af van de context die je veilig en volledig aanlevert.

Moet ik mijn hele codebase uploaden?

Nee. Begin met relevante routes, middleware, policies, env-voorbeeldbestanden en config. Plak nooit echte secrets. Voor een volledige codebase audit werk je bij voorkeur in een lokale of gecontroleerde omgeving.

Wat is het grootste risico bij vibe-coded apps?

Het grootste risico is dat werkende code wordt verward met veilige code. Vooral server-client grenzen, ontbrekende auth checks, hardcoded secrets en te ruime data policies komen vaak laat aan het licht.

Wat doet de URL mode?

URL mode kijkt non-destructief naar openbare signalen zoals security headers, cookies, gevoelige paden, source map signalen, technologiehints en zichtbare client bundle informatie. Test alleen URL's waar je toestemming voor hebt.

Wat doe ik na de audit?

Fix Critical en High bevindingen eerst, schrijf per fix bewijs op en draai de relevante checks opnieuw. Pas daarna behandel je Medium en Low punten zoals hardening, documentatie en terugkerende releasechecks.