Sådan sikrer du AI-genereret kode — Vibe Coding Security Checklist

Hvis du har lavet en app med Claude eller Cursor og er ved at overdrage den til en betalende klient, stop. AI-genereret kode kommer med forudsigelige sikkerhedshulller — blottede API-nøgler, manglende input-validering, standarddatabasetilladelser, der lader alle brugere se alle andres data. Dette er ikke edge cases. Det sker i næsten hver AI-genereret kodebase ved første forsøg.

Denne guide er sikkerhedstjeklisten før lancering. Følg den trin for trin, før nogle rigtige brugere får adgang til din app. Den er skrevet til den mest almindelige vibe coding-stak (Next.js + Supabase + Vercel), men principperne gælder uanset hvilke værktøjer du bruger.

Hvorfor AI-genereret kode har sikkerhedsproblemer

AI-modeller optimerer for "virker det?" ikke "er det sikkert?" Når du fortæller Claude "lav mig en opgavehåndterer med brugerkonti," genererer den kode, der opretter brugere, gemmer opgaver og viser dem. Det, den sandsynligvis ikke automatisk gør: sikre, at bruger A ikke kan se bruger B's opgaver, validere, at inputfelter ikke kan acceptere ondsindet script, gemme dine API-nøgler fra browserens udviklerværktøjer, eller tilføje hastighedsbegrænsning for at forhindre, at nogen hamrer dine endpoints.

Det her er ikke fejl fra AI'en — det er huller i promptet. AI'en bygger hvad du bad om. Du bad sandsynligvis ikke om sikkerhed, fordi du fokuserede på funktioner. Nu er det tid til at gå tilbage og tilføje det.

Trin 1: Audit dine miljøvariabler

Dette er den mest almindelige og farligste fejl i vibe-kodede apps. Kontroller alle filer i dit projekt for hardcodede API-nøgler, databaseadresser eller hemmeligheder.

Hvad du skal lede efter: Søg i din kodebase efter strenge, der starter med sk-, eyJ, sbp_, supabase, postgres://, eller lange tilfaldigt udseende strenge. Kontroller disse filer specifikt: alle filer i din /app eller /pages mappe, alle komponentfiler, din next.config.js, og alle utility-filer.

Løsningen: Flyt alle hemmeligheder til miljøvariabler. I Next.js er kun variabler med præfikset NEXT_PUBLIC_ blottet for browseren. Din databaseadresse, servicerolle-nøgle og API-hemmeligheder skal aldrig have dette præfiks.

# .env.local (ALDRIG commit denne fil)
SUPABASE_SERVICE_ROLE_KEY=your-secret-key
DATABASE_URL=postgres://...

# Disse er okay at blotte for browseren:
NEXT_PUBLIC_SUPABASE_URL=https://your-project.supabase.co
NEXT_PUBLIC_SUPABASE_ANON_KEY=your-anon-key

Verificer: Kontroller, at din .gitignore fil inkluderer .env.local. Hvis du allerede har committed hemmeligheder til Git, er de i din historie selv efter sletning — roter (regenerer) alle blottede nøgler øjeblikkeligt.

Trin 2: Aktivér Row-Level Security i Supabase

Dette er det enkelte vigtigste trin, hvis du bruger Supabase. Som standard har Supabase-tabeller ingen adgangsbegrænsninger — enhver med din anon-nøgle kan læse og skrive hver række i hver tabel. Det betyder bruger A kan se bruger B's data med et simpelt API-kald.

Løsningen: Aktivér Row-Level Security (RLS) på hver tabel, og opret derefter politikker, der begrænser adgangen.

Gå til dit Supabase-dashboard → Table Editor → vælg hver tabel → klik "RLS Disabled" for at aktivere det. Tilføj derefter politikker:

For en typisk app, hvor brugere kun skal se deres egne data, opret en SELECT-politik: auth.uid() = user_id. Opret lignende politikker for INSERT, UPDATE og DELETE.

Test det: Log ind som bruger A, prøv at få adgang til bruger B's data gennem API'en. Hvis du kan se det, er dine politikker forkerte. Supabase har en SQL-editor, hvor du kan teste politikker direkte.

Almindelig AI-fejl: Claude genererer ofte Supabase-forespørgsler ved hjælp af service_role nøglen (som omgår RLS) i stedet for anon nøglen med korrekte RLS-politikker. Kontroller, at din client-side-kode kun bruger anon-nøglen. Servicerolle-nøglen bør kun eksistere i server-side-kode (API-ruter, serverhandlinger) og aldrig blottet for browseren.

Trin 3: Tilføj autentificering korrekt

AI-genereret auth-kode virker ofte, men tager genveje. Kontroller disse specifikke problemer:

Sessionshåndtering: Sørg for, at sessioner udløber. Kontroller, at din auth-setup inkluderer en rimelig sessionstimeout (Supabase-standarder er generelt fine, men verificer). Sikrer, at logout faktisk invaliderer sessionen, ikke kun sletter den lokale cookie.

Passwordkrav: Hvis du har email/password-auth, håndhæv minimumlængde for kodeord (8+ tegn). Supabase håndterer dette i dine projektindstillinger → Authentication → Password Requirements.

Beskyttede ruter: Hver side, der viser brugerspecifikt data, skal have autentificerings-middleware. I Next.js App Router, opret en middleware, der checker en gyldig session og omdirigerer uautentificerede brugere til login-siden. Stol ikke kun på client-side-checks — en bruger kan omgå dem ved at ramme din API direkte.

Email-verifikation: Aktivér email-bekræftelse i Supabase Auth-indstillingerne. Dette forhindrer mennesker i at oprette konti med falske e-mailadresser og tilføjer et grundlæggende lag af kontovaliditet.

Trin 4: Validér alle inputs

AI-genererede formularer har normalt grundlæggende validering (påkrævede felter, email-format), men sjældent beskyttelse mod ondsindet input.

Hvad du skal tilføje:

Server-side validering på hvert API-endpoint. Stol aldrig alene på client-side validering — det kan omgås ved at sende anmodninger direkte til din API. Brug et valideringsbibliotek som Zod (til TypeScript) for at definere skemaer for hver data-del, din app accepterer.

Rens HTML i ethvert bruger-genereret indhold, der vises. Hvis din app har kommentarer, beskrivelser eller ethvert tekstfelt, der renders i browseren, brug et bibliotek som DOMPurify til at fjerne ondsindet script. Uden dette kan nogen injicere JavaScript, der stjæler andre brugeres sessioner (cross-site scripting / XSS).

Begræns filuploadstørrelse og -typer, hvis din app accepterer filupload. AI-genererede uploadhandlere har ofte ingen grænser, hvilket betyder nogen kunne uploade en 2GB-fil eller en eksekverbar. Tilføj størrelsesgrænser (5MB er rimeligt for de fleste apps) og begræns filtyper til hvad du faktisk har brug for (billeder, PDF'er osv.).

Trin 5: Sikr dine API-ruter

Kontroller hver API-rute eller serverhandling i din app for disse problemer:

Autentificering på hvert endpoint. Hver API-rute, der returnerer eller ændrer brugerdata, skal først verificere brugerens session. AI genererer ofte API-ruter, der accepterer anmodninger fra alle.

Autorisering ud over autentificering. Selv efter at bekræfte, at en bruger er logget ind, verificeres, at de har tilladelse til at få adgang til den specifikke ressource, de anmoder om. "Bruger A er logget ind" betyder ikke "Bruger A kan redigere bruger B's profil." Kontroller ejerskab ved hver dataaktion.

Hastighedsbegrænsning. Uden hastighedsbegrænsning kan nogen sende tusinder af anmodninger pr. sekund til din API, enten for at skrabe data eller for at overvælde din server. Tilføj grundlæggende hastighedsbegrænsning ved hjælp af et bibliotek som rate-limiter-flexible eller brug Vercels indbyggede hastighedsbegrænsning på Edge Functions.

HTTP-metoder. Sørg for, at dine API-ruter kun reagerer på de HTTP-metoder, de skal. En rute, der håndterer POST-anmodninger, bør ikke også reagere på DELETE-anmodninger, medmindre du eksplicit designede den til det.

Trin 6: Kontroller din implementeringskonfiguration

Din implementeringsplatform har sikkerhedsindstillinger, som AI ikke konfigurerer for dig.

Vercel-indstillinger at kontrollere: Aktivér "Deployment Protection" (kræver auth for at se forhåndsvisningsimplementeringer — forhindrer klienter i at dele forhåndsvisnings-URL'er, der blotter igangværende arbejde). Opstil udgiftsbegrænsninger for at forhindre uventede gebyrer, hvis din app får trafikspidser. Konfigurer dine tilladte domæner i CORS-headers.

Brugerdefineret domæne og SSL: Hvis du leverer dette til en klient, skal du konfigurere deres brugerdefinerede domæne med HTTPS. Vercel og Netlify håndterer SSL automatisk. Lever aldrig en klient-app på et .vercel.app underdomæne — det ser uprofessionelt ud, og klienten kan ikke overføre det nemt.

Headers: Tilføj sikkerhedsheaders til din next.config.js eller vercel.json: X-Content-Type-Options: nosniff, X-Frame-Options: DENY (forhindrer dit websted i at blive indlejret i iframes for clickjacking), Strict-Transport-Security (tvinger HTTPS). Disse er engangsudgaver, der forhindrer hele klasser af angreb.

Trin 7: Kør en slutsikkerhedsscan

Før du overdrage noget til en klient, skal du køre disse gratis checks:

npm audit: Kør npm audit i din projektmappe. Det markerer kendte sårbarheder i dine afhængigheder. Løs kritiske og høj-alvorligheds-problemer. Kør npm audit fix for automatiske rettelser, hvor der er muligt.

Lighthouse: Åbn dit implementerede websted i Chrome, åbn DevTools, kør en Lighthouse-audit. Kontroller "Best Practices"-scoren — det fanget almindelige sikkerhedsproblemer som manglende HTTPS, sårbare biblioteker og usikre headers.

Manuel test: Log ind som en bruger, prøv at få adgang til en anden brugers data ved at ændre URL'er eller API-kald. Prøv at indsende tomme formularer, oversizedede inputs og special tegn (som kodede XSS-payloads). Hvis nogen af disse virker, har du problemer at rette.

Tjeklisten før lancering

Udskriv dette og marker hver punkt før live:

• Alle hemmeligheder i miljøvariabler (ingen hardcodede nøgler)
• .env.local i .gitignore (og ingen hemmeligheder i Git-historik)
• Supabase RLS aktiveret på hver tabel
• RLS-politikker testet (bruger A kan ikke se bruger B's data)
• Client-side-kode bruger kun anon-nøgle (servicerolle-nøgle kun server-side)
• Autentificering på hvert API-endpoint
• Autorisationskontroller (ejerskabsverifikation) ved dataaktion
• Input-validering på hver formular (server-side, ikke kun client-side)
• Filuploadgrænser (størrelse og type) hvis relevant
• Hastighedsbegrænsning på API-endpoints
• Sikkerhedsheaders konfigureret
• npm audit kørt og kritiske problemer rettet
• Brugerdefineret domæne med SSL konfigureret
• Forhåndsvisningsimplementeringer beskyttet
• Manuel test af cross-bruger-dataaktion bestået

Bundlinjen

Sikring af en vibe-kodet app handler ikke om at blive sikkerhedsekspert. Det handler om at køre gennem en tjekliste, der fanget forudsigelige huller, AI efterlader. Trinene ovenfor tager 2–4 timer og forhindrer de mest almindelige sårbarheder. For en klient-vendt app er dette ikke valgfrit — det er forskellen mellem professionelt arbejde og en ansvar.

Hvis du bygger din første vibe-kodede app, start med vores fuldstændige guide til vibe coding. Hvis du vil forbedre de prompts, du bruger med Claude eller Cursor, prøv vores gratis prompt optimizer. Og for en oversigt over de bedste kodningsværktøjer, se Claude Code vs Codex.

Offentliggørelse: Nogle links i denne artikel er affiliate-links. Vi anbefaler kun værktøjer, vi personligt har testet og bruger regelmæssigt. Se vores fuldstændige oplysningspolitik.