Sådan sikrer du en Vibe-Coded App, før du giver den til kunder

Hvis du har lavet en app med Claude eller Cursor ved hjælp af vibe coding, og du er ved at overlevere den til en betalende klient, stop. AI-genereret kode leveres med forudsigelige sikkerhedshullær — eksponerede API-nøgler, manglende inputvalidering, standarddatabasetilladelser, der lader alle brugere se andres data. Dette er ikke grænsecases. Det sker i næsten hver første version af AI-genereret kodebase.

Denne guide er sikkerhedstjeklisten før lancering. Følg den trin for trin, før en rigtig bruger rører ved din app. Den er skrevet til den mest almindelige vibe coding stack (Next.js + Supabase + Vercel), men principperne gælder uanset dine værktøjer.

Hvorfor AI-genereret kode har sikkerhedsproblemer

AI-modeller optimerer for "virker det?" ikke "er det sikkert?" Når du siger til Claude "byg mig en opgavemanager med brugerkonti," vil det generere kode, der opretter brugere, gemmer opgaver og viser dem. Det vil sandsynligvis ikke automatisk: sikre, at bruger A ikke kan se bruger B's opgaver, validere, at inputfelter ikke kan acceptere ondsindet scripts, skjule dine API-nøgler fra browserens udviklerværktøjer, eller tilføje hastighedsbegrænsning for at forhindre, at nogen hammerer dine endpoints.

Dette er ikke fejl fra AI'en — det er huller i prompten. AI'en bygger det, du bed 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: Revider dine miljøvariabler

Dette er den mest almindelige og mest farlige fejl i vibe-codede apps. Tjek hver fil i dit projekt for hardcodede API-nøgler, database-URL'er eller hemmeligheder.

Hvad du skal lede efter: Søg i din kodebase efter strenge, der starter med sk-, eyJ, sbp_, supabase, postgres://, eller lange tilfældige strenge. Tjek disse filer specifikt: enhver fil i dine /app eller /pages mapper, enhver komponentfil, din next.config.js, og eventuelle utility-filer.

Løsningen: Flyt hver hemmelighed til miljøvariabler. I Next.js exponeres kun variabler præfikset med NEXT_PUBLIC_ til browseren. Din database-URL, service role-nøgle og API-hemmeligheder bør aldrig have dette præfiks.

# .env.local (COMMIT ALDRIG denne fil)
SUPABASE_SERVICE_ROLE_KEY=din-hemmeligt-nøgle
DATABASE_URL=postgres://...

# Det er okay at expose til browseren:
NEXT_PUBLIC_SUPABASE_URL=https://dit-projekt.supabase.co
NEXT_PUBLIC_SUPABASE_ANON_KEY=din-anon-nøgle

Verifikation: Tjek din .gitignore-fil inkluderer .env.local. Hvis du allerede har committed hemmeligheder til Git, er de i din historie, selv efter sletning — roter (regenerer) hver exponeret nøgle øjeblikkeligt.

Trin 2: Aktiver Row-Level Security i Supabase

Dette er det mest kritiske 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. Dette betyder, at bruger A kan se bruger B's data med et simpelt API-kald.

Løsningen: Aktiver 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 på "RLS Disabled" for at aktivere det. Derefter tilføjer du politikker:

For en typisk app, hvor brugere kun skal se deres egne data, skal du oprette 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 via 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 ordentlige RLS-politikker. Tjek, at din klientside-kode kun bruger anon-nøglen. Service role-nøglen bør kun findes i serverside-kode (API-ruter, serverhandlinger) og aldrig exponeres til browseren.

Trin 3: Tilføj autentificering korrekt

AI-genereret auth-kode fungerer ofte, men tager genveje. Tjek disse specifikke problemer:

Sessionsstyring: Sørg for, at sessioner udløber. Tjek, at din auth-opsætning inkluderer en rimelig session timeout (Supabase-standarder er generelt fine, men verificer). Sikr, at log ud faktisk invaliderer sessionen, ikke bare rydder den lokale cookie.

Passwordkrav: Hvis du har email/password-autentificering, skal du håndhæve minimumpassordlængde (8+ tegn). Supabase håndterer dette i dine projektindstillinger → Autentificering → Passwordkrav.

Beskyttede ruter: Hver side, der viser brugerspecifikke data, har brug for autentificerings middleware. I Next.js App Router skal du oprette en middleware, der kontrollerer for en gyldig session, og omdirigerer ikke-godkendte brugere til login-siden. Stol ikke alene på klientside-checks — en bruger kan omgå disse ved direkte at få adgang til din API.

Email-bekræftelse: Aktiver email-bekræftelse i Supabase Auth-indstillinger. Dette forhindrer folk i at oprette konti med falske emailadresser og tilføjer et grundlæggende lag af kontogyldighedskontrol.

Trin 4: Valider alle inputs

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

Hvad du skal tilføje:

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

Desinficér HTML i ethvert brugeroprettet indhold, der vises. Hvis din app har kommentarer, beskrivelser eller ethvert tekstfelt, der renders i browseren, skal du bruge et bibliotek som DOMPurify til at fjerne farlige scripts. Uden dette kan nogen injicere JavaScript, der stjæler andres sessioner (cross-site scripting / XSS).

Begræns filuploadstørrelse og -typer, hvis din app accepterer filuploadinger. AI-genererede upload-handlere har ofte ingen grænser, hvilket betyder, at 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

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

Autentificering på hver 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.

Godkendelse ud over autentificering. Selv efter at bekræfte, at en bruger er logget ind, skal du verificere, at de må få adgang til den specifikke ressource, de anmoder. "Bruger A er logget ind" betyder ikke "Bruger A kan redigere bruger B's profil." Tjek ejerskab ved hver dataadgang.

Hastighedsbegrænsning. Uden hastighedsbegrænsning kan nogen sende tusindvis af anmodninger pr. sekund til din API, enten for at skrabe data eller for at overbelaste serveren. Tilføj grundlæggende hastighedsbegrænsning ved hjælp af et bibliotek som rate-limiter-flexible, eller brug Vercel's 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 heller ikke reagere på DELETE-anmodninger, medmindre du eksplicit designede det.

Trin 6: Tjek din deployment-konfiguration

Din deployment-platform har sikkerhedsindstillinger, som AI ikke konfigurerer for dig.

Vercel-indstillinger at tjekke: Aktiver "Deployment Protection" (kræver autentificering for at se preview-deployments — forhindrer klienter i utilsigtet at dele preview-URL'er, der exponerer igangværende arbejde). Opsæt udgiftsgræns for at forhindre uventede udgifter, hvis din app får trafikstigning. Konfigurer dine tilladt domæner i CORS-headers.

Brugerdefineret domæne og SSL: Hvis du leverer dette til en klient, skal du opsætte 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 uindustrielt 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, at dit site er indlejret i iframes for clickjacking), Strict-Transport-Security (tvinger HTTPS). Disse er engangsadditioner, der forhindrer hele klasser af angreb.

Trin 7: Kør en endelig sikkerhedsscan

Før du overleverer 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. Fiks kritiske og høj-prioritets-problemer. Kør npm audit fix for automatiske rettelser, hvor det er muligt.

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

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

Tjeklisten før lancering

Print dette og tjek hver punkt før live-lancering:

• 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)
• Klientside-kode bruger kun anon-nøgle (service role-nøgle kun serverside)
• Autentificering på hver API-rute
• Godkendelsestjek (ejerskabsbekræftelse) ved dataadgang
• Inputvalidering på hver formular (serverside, ikke bare klientside)
• Filuploadgrænser (størrelse og type) hvis relevant
• Hastighedsbegrænsning på API-endpoints
• Sikkerhedsheaders konfigureret
• npm audit kørt og kritiske problemer fikset
• Brugerdefineret domæne med SSL konfigureret
• Preview-deployments beskyttet
• Manuel test af bruger-til-bruger-dataadgang bestået

Essensen

At sikre en vibe-codet app handler ikke om at blive sikkerhedsekspert. Det handler om at løbe gennem en tjekliste, der fanger de forudsigelige huller, som 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 et ansvar.

Hvis du bygger din første vibe-codede app, start med vores komplette 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 sammenbrudning af de bedste kodningsværktøjer, se Claude Code vs Codex.

Oplysning: 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 oplysnignspolitik.