Hoe je een Vibe-Coded App beveiligt voordat je deze aan klanten geeft

Als je een app met Claude of Cursor hebt gecodeerd en je gaat het aan een betalende klant geven, stop. AI-gegenereerde code wordt geleverd met voorspelbare beveiligingsgaten — blootgestelde API-sleutels, ontbrekende inputvalidatie, standaard databaserechten waarmee elke gebruiker de gegevens van iedereen kan zien. Dit zijn geen randgevallen. Ze komen voor in vrijwel elke eerste versie van AI-gegenereerde codebases.

Deze gids is de beveiligingschecklist vóór de lancering. Volg dit stap voor stap voordat echte gebruikers je app gebruiken. Het is geschreven voor de meest voorkomende vibe coding stack (Next.js + Supabase + Vercel), maar de principes gelden ongeacht welke tools je gebruikt.

Waarom AI-gegenereerde code beveiligingsproblemen heeft

AI-modellen optimaliseren voor "werkt het?" niet "is het veilig?" Als je Claude zegt "bouw me een taakbeheerder met gebruikersaccounts", genereert het code die gebruikers aanmaakt, taken opslaat en toont. Wat het waarschijnlijk niet automatisch doet: ervoor zorgen dat Gebruiker A de taken van Gebruiker B niet kan zien, valideren dat invoervelden geen malafide scripts kunnen accepteren, je API-sleutels verbergen voor de developer tools van de browser, of snelheidslimieten toevoegen om te voorkomen dat iemand je endpoints overbelast.

Dit zijn geen fouten van de AI — het zijn gaten in de prompt. De AI bouwt wat je vraagt. Je hebt waarschijnlijk niet om beveiliging gevraagd omdat je gericht was op functies. Nu is het tijd om terug te gaan en het toe te voegen.

Stap 1: Controleer je omgevingsvariabelen

Dit is de meest voorkomende en gevaarlijkste fout in vibe-coded apps. Controleer elk bestand in je project op hardcoded API-sleutels, database-URL's of geheimen.

Waar je naar moet zoeken: Zoek in je codebase naar tekenreeksen die beginnen met sk-, eyJ, sbp_, supabase, postgres://, of andere lange willekeurig lijkende tekenreeksen. Controleer deze bestanden specifiek: elk bestand in je /app of /pages directory, elk componentbestand, je next.config.js, en elk utilitybestand.

De oplossing: Verplaats elk geheim naar omgevingsvariabelen. In Next.js zijn alleen variabelen met het voorvoegsel NEXT_PUBLIC_ zichtbaar voor de browser. Je database-URL, service role key en API-geheimen mogen nooit dit voorvoegsel hebben.

# .env.local (NOOIT committen naar dit bestand)
SUPABASE_SERVICE_ROLE_KEY=your-secret-key
DATABASE_URL=postgres://...

# Deze zijn oké om bloot te stellen aan de browser:
NEXT_PUBLIC_SUPABASE_URL=https://your-project.supabase.co
NEXT_PUBLIC_SUPABASE_ANON_KEY=your-anon-key

Controleren: Controleer dat je .gitignore bestand .env.local bevat. Als je al geheimen naar Git hebt gecommit, zijn ze in je geschiedenis — zelfs na verwijdering — dus rotateer (regenereer) onmiddellijk elke blootgestelde sleutel.

Stap 2: Schakel Row-Level Security in Supabase in

Dit is de enige meest kritieke stap als je Supabase gebruikt. Standaard hebben Supabase-tabellen geen toegangsbeperkingen — iedereen met je anon key kan elke rij in elke tabel lezen en schrijven. Dit betekent dat Gebruiker A de gegevens van Gebruiker B kan zien met een eenvoudige API-aanroep.

De oplossing: Schakel Row-Level Security (RLS) in op elke tabel en maak vervolgens beleid dat toegang beperkt.

Ga naar je Supabase-dashboard → Table Editor → selecteer elke tabel → klik op "RLS Disabled" om het in te schakelen. Voeg vervolgens beleid toe:

Voor een typische app waar gebruikers alleen hun eigen gegevens moeten zien, maak je een SELECT-beleid: auth.uid() = user_id. Maak soortgelijk beleid voor INSERT, UPDATE en DELETE.

Test het: Log in als Gebruiker A, probeer via de API toegang te krijgen tot de gegevens van Gebruiker B. Als je het kunt zien, is je beleid fout. Supabase heeft een SQL-editor waar je beleid direct kunt testen.

Veelvoorkomende AI-fout: Claude genereert Supabase-queries vaak met de service_role key (die RLS omzeilt) in plaats van de anon key met correct RLS-beleid. Controleer dat je client-side code alleen de anon key gebruikt. De service role key mag alleen bestaan in server-side code (API-routes, server actions) en mag nooit aan de browser worden blootgesteld.

Stap 3: Voeg authenticatie correct toe

AI-gegenereerde auth-code werkt vaak, maar neemt snelkoppelingen. Controleer op deze specifieke problemen:

Sessiebeheer: Zorg ervoor dat sessies verlopen. Controleer dat je auth-setup een redelijke sessietimeout bevat (Supabase-standaardinstellingen zijn meestal prima, maar verifieer). Zorg ervoor dat u afmelden daadwerkelijk de sessie ongeldig maakt, niet alleen de lokale cookie wist.

Wachtwoordvereisten: Als je email/wachtwoord-authenticatie hebt, zet minimale wachtwoordlengte af (8+ tekens). Supabase handelt dit af in je projectinstellingen → Authentication → Password Requirements.

Beveiligde routes: Elke pagina die gebruikersspecifieke gegevens toont, heeft authenticatiemiddleware nodig. In Next.js App Router, maak je middleware die controleert op een geldige sessie en stuurt niet-geverifieerde gebruikers naar de inlogpagina. Vertrouw niet alleen op client-side controles — een gebruiker kan deze omzeilen door rechtstreeks je API aan te roepen.

E-mailverificatie: Schakel e-mailbevestiging in in Supabase Auth-instellingen. Dit voorkomt dat mensen accounts maken met nep-e-mailadressen en voegt een basislaag van accountgeldigheid toe.

Stap 4: Valideer alle invoer

AI-gegenereerde formulieren hebben meestal basisvalidatie (verplichte velden, e-mailindeling), maar beschermen zelden tegen malafide invoer.

Wat je moet toevoegen:

Server-side validatie op elk API-eindpunt. Vertrouw nooit alleen op client-side validatie — deze kan worden omzeild door verzoeken rechtstreeks naar je API te sturen. Gebruik een validatiebibliotheek zoals Zod (voor TypeScript) om schema's voor elk gegeven dat je app accepteert, te definiëren.

Zet HTML schoon in door gebruiker gegenereerde inhoud die in de browser wordt weergegeven. Als je app opmerkingen, beschrijvingen of een tekstvel bevat dat wordt weergegeven, gebruik je een bibliotheek zoals DOMPurify om gevaarlijke scripts te verwijderen. Zonder dit kan iemand JavaScript injecteren die sessies van andere gebruikers steelt (cross-site scripting / XSS).

Beperk de grootte en types van bestandsuploads als je app bestandsuploads accepteert. AI-gegenereerde uploadhandlers hebben vaak geen limieten, dus iemand kan een 2GB-bestand of een uitvoerbaar bestand uploaden. Voeg groottelimieten toe (5MB is redelijk voor de meeste apps) en beperk bestandstypes tot wat je daadwerkelijk nodig hebt (afbeeldingen, PDF's, enz.).

Stap 5: Beveilig je API-routes

Controleer elke API-route of server action in je app op deze problemen:

Authenticatie op elk eindpunt. Elke API-route die gebruikersgegevens retourneert of wijzigt, moet eerst de sessie van de gebruiker verifiëren. AI genereert vaak API-routes die verzoeken van iedereen accepteren.

Autorisatie voorbij authenticatie. Zelfs na bevestiging dat een gebruiker is ingelogd, moet je verifiëren dat ze toegang hebben tot de specifieke resource die ze aanvragen. "Gebruiker A is ingelogd" betekent niet "Gebruiker A kan het profiel van Gebruiker B bewerken." Controleer eigenaarschap op elke gegevenstoegang.

Snelheidsbeperking. Zonder snelheidsbeperking kan iemand duizenden verzoeken per seconde naar je API sturen, hetzij om gegevens te schrapen hetzij om je server te overbelasten. Voeg basissnelheidsbeperking toe met behulp van een bibliotheek zoals rate-limiter-flexible of gebruik Vercel's ingebouwde snelheidsbeperking op Edge Functions.

HTTP-methoden. Zorg ervoor dat je API-routes alleen reageren op de HTTP-methoden die ze zouden moeten. Een route die POST-verzoeken verwerkt, mag niet ook op DELETE-verzoeken reageren, tenzij je het expliciet zo hebt ontworpen.

Stap 6: Controleer je implementatieconfiguratie

Je implementatieplatform heeft beveiligingsinstellingen die AI niet voor je configureert.

Vercel-instellingen om te controleren: Schakel "Deployment Protection" in (vereist authenticatie om preview-implementaties te bekijken — voorkomt dat klanten per ongeluk preview-URL's delen die work-in-progress blootleggen). Stel uitgavenslimieten in om onverwachte kosten te voorkomen als je app verkeerspieken krijgt. Configureer je toegestane domeinen in CORS-headers.

Aangepast domein en SSL: Als je dit aan een klant levert, stel je hun aangepaste domein in met HTTPS. Vercel en Netlify verwerken SSL automatisch. Lever nooit een client-app op een .vercel.app subdomein — dit ziet er onprofessioneel uit en de klant kan het niet gemakkelijk overdragen.

Headers: Voeg beveiligingsheaders toe aan je next.config.js of vercel.json: X-Content-Type-Options: nosniff, X-Frame-Options: DENY (voorkomt dat je site in iframes wordt ingesloten voor clickjacking), Strict-Transport-Security (dwingt HTTPS af). Dit zijn eenmalige toevoegingen die hele klassen aanvallen voorkomen.

Stap 7: Voer een laatste beveiligingsscan uit

Voordat je iets aan een klant overhangt, voer je deze gratis controles uit:

npm audit: Voer npm audit uit in je projectdirectory. Het geeft bekende kwetsbaarheden in je afhankelijkheden aan. Repareer kritieke en hogeernstproblemen. Voer npm audit fix uit voor automatische reparaties waar beschikbaar.

Lighthouse: Open je geïmplementeerde site in Chrome, open DevTools, voer een Lighthouse-audit uit. Controleer de "Best Practices"-score — het vangt veel voorkomende beveiligingsproblemen op zoals ontbrekende HTTPS, kwetsbare bibliotheken en onveilige headers.

Handmatig testen: Log in als de ene gebruiker, probeer via de ander gebruiker's gegevens te benaderen door URL's of API-aanroepen aan te passen. Probeer lege formulieren, oversized invoer en speciale tekens in te dienen (zoals gecodeerde XSS-payloads). Als iets hiervan werkt, heb je problemen om op te lossen.

De pre-launch checklist

Print dit en controleer elk item voordat je online gaat:

• Alle geheimen in omgevingsvariabelen (geen hardcoded sleutels)
• .env.local in .gitignore (en geen geheimen in Git-geschiedenis)
• Supabase RLS ingeschakeld op elke tabel
• RLS-beleid getest (Gebruiker A kan Gebruiker B's gegevens niet zien)
• Client-side code gebruikt alleen anon key (service role key alleen server-side)
• Authenticatie op elke API-route
• Autorisatiecontroles (eigendomsverificatie) op gegevenstoegang
• Inputvalidatie op elk formulier (server-side, niet alleen client-side)
• Bestandsuploadslimieten (grootte en type) indien van toepassing
• Snelheidsbeperking op API-eindpunten
• Beveiligingsheaders geconfigureerd
• npm audit uitgevoerd en kritieke problemen opgelost
• Aangepast domein met SSL geconfigureerd
• Preview-implementaties beveiligd
• Handmatige cross-user gegevenstoegangtest geslaagd

De kernboodschap

Het beveiligen van een vibe-coded app gaat niet om beveiligingsexpert worden. Het gaat om een checklist af te werken die de voorspelbare gaten die AI achterlaat, vangt. De stappen hierboven nemen 2–4 uur in beslag en voorkomen de meest voorkomende kwetsbaarheden. Voor een klant-facing app is dit niet optioneel — het is het verschil tussen professioneel werk en een aansprakelijkheid.

Als je je eerste vibe-coded app bouwt, begin dan met onze complete gids voor vibe coding. Als je de prompts die je met Claude of Cursor gebruikt, wilt verbeteren, probeer onze gratis prompt optimizer. En voor een overzicht van de beste coderingsprogramma's, zie Claude Code vs Codex.

Openbaarmakingen: Sommige links in dit artikel zijn affiliate-links. We raden alleen tools aan die we persoonlijk hebben getest en regelmatig gebruiken. Zie ons volledige openbaarmakingsbeleid.