5 sikkerhedsfejl, som hver Vibe Coder laver (og hvordan du fikser dem)

AI-genereret kode fungerer. Den kører. Den ser rigtig ud. Den leveres også med de samme fem sikkerhedssårbarheder i næsten hvert projekt. Dette er ikke teoretiske risici — de er de specifikke huller, der dukker op i næsten alle kodebaser produceret af Claude, Cursor, Replit eller Copilot, når du ikke eksplicit spørger efter sikkerhed.

Jeg har gennemgået dusinvis af vibe-kodede projekter over det seneste år, og de samme fem fejl optræder i mindst 80% af dem. Hver enkelt tager mindre end 30 minutter at rette. Her er hvad du skal lede efter og præcis hvordan du retter det.

Fejl 1: API-nøgler hardkodet i Frontend-kode

Hvordan det sker: Du fortæller Claude "opret forbindelse til Supabase" eller "tilføj Stripe-betalinger," og det genererer kode med API-nøglen indsat direkte i en React-komponent. Koden fungerer perfekt — og din hemmelige nøgle er synlig for alle, der åbner browser DevTools og tjekker Network-fanen eller JavaScript-kilden.

Hvorfor det er farligt: Din Supabase service role-nøgle omgår all database-sikkerhed. Din Stripe hemmelige nøgle lader nogen opkræve kort eller udstede refusioner. Din OpenAI-nøgle lader nogen samle tusinder i API-opkald på din konto. Bots scanner aktivt offentlige GitHub-repos og udrullede sites efter blotlagte nøgler.

Løsningen: Flyt alle hemmeligheder til miljøvariabler. I Next.js når kun variabler startende med NEXT_PUBLIC_ browseren. Enhver nøgle, der giver skriveadgang, adminadgang eller økonomisk adgang, skal være kun på server-siden.

Efter at have flyttet nøgler til .env.local, søg i hele dit kodebase efter de gamle nøgleværdier for at sikre, de er væk. Tjek derefter din Git-historie — hvis nøglen nogensinde blev committed, er den stadig i dit repo-historie selv hvis du slettede den. Regenerer (roter) enhver nøgle, der nogensinde blev blotlagt, selv kort.

Tid til at rette: 15–30 minutter.

Fejl 2: Supabase-tabeller uden Row-Level Security

Hvordan det sker: AI genererer Supabase-tabeloprettelsesforespørgsler og CRUD-operationer, men aktiverer ikke Row-Level Security (RLS). Som standard er Supabase-tabeller med RLS deaktiveret fuldt tilgængelige for alle med dit projekt-URL og anon-nøgle — begge dele er offentlige (og bør være).

Hvorfor det er farligt: Uden RLS kan Bruger A forespørge Bruger B's data. Et simpelt fetch-kald fra browser-konsollen kan trække alle rækker fra alle tabeller. Din hele database er effektivt offentlig.

Hvordan du opdager det: Gå til dit Supabase-dashboard → Table Editor. Hvis en tabel viser "RLS Disabled," har du dette problem. Tjek også om din client-side-kode bruger service_role-nøglen i stedet for anon-nøglen — det er endnu værre.

Løsningen: Aktivér RLS på alle tabeller. Opret derefter politikker, der matcher din apps adgangsmønstre. Den mest almindelige politik: brugere kan kun SELECT, INSERT, UPDATE og DELETE rækker hvor auth.uid() = user_id. Test ved at logge ind som en bruger og forsøge at få adgang til en anden brugers data gennem Supabase REST API.

Tid til at rette: 30–60 minutter afhængig af tabelantal.

Fejl 3: Ingen inputvalidering på formularer eller API-ruter

Hvordan det sker: AI genererer formularer, der accepterer ethvert input og API-ruter, der stoler på hvad end data der kommer ind. Formularen har et "required"-attribut i HTML, men ingen server-side validering. Nogen omgår formularen helt ved at sende en direkte API-anmodning med hvad end payload de ønsker.

Hvorfor det er farligt: Uden server-side validering kan angribere injicere scripts ind i din database (lagret XSS), sende oversized payloads, der kan ned dit server, eller indsende data, der bryder din apps logik (som en negativ pris eller et emailfelt indeholdende SQL).

Hvordan du opdager det: Åbn enhver API-rute eller server-handling i dit kodebase. Hvis den bruger req.body eller formulardata uden at kontrollere formen, typen og længden af hvert felt, har du dette problem.

Løsningen: Tilføj server-side validering til hvert endpoint ved hjælp af et schema-validerings-bibliotek. Zod er standarden for TypeScript-projekter:

import { z } from 'zod';

const taskSchema = z.object({
  title: z.string().min(1).max(200),
  description: z.string().max(2000).optional(),
  priority: z.enum(['low', 'medium', 'high']),
});

// In your API route:
const parsed = taskSchema.safeParse(req.body);
if (!parsed.success) {
  return Response.json({ error: parsed.error }, { status: 400 });
}

For ethvert felt der bliver renderet som HTML (kommentarer, beskrivelser, bios), skal du også sanitere output med DOMPurify før visning.

Tid til at rette: 30–60 minutter.

Fejl 4: Ingen rate limiting på API-endepunkter

Hvordan det sker: AI tilføjer aldrig rate limiting medmindre du spørger om det. Hvert API-endpoint din app blotlægger kan rammes tusinder af gange per sekund af alle med et script.

Hvorfor det er farligt: Uden rate limiting kan nogen brute-force dit login-endpoint, skrabe din database ved gentagne gange at ramme list-endpoints, overvælde din server (denial of service), eller brænde gennem din API-kvote hvis dine endpoints kalder eksterne tjenester som OpenAI eller Stripe.

Hvordan du opdager det: Hvis ingen af dine API-ruter tjekker hvor mange anmodninger en enkelt IP eller bruger har lavet for nylig, har du ingen rate limiting.

Løsningen: Den enkleste tilgang for Vercel-hostede apps er en in-memory rate limiter til udvikling og en Redis-baseret til produktion. Vercels Edge Middleware kan håndtere grundlæggende rate limiting. Upstash Redis (gratis tier) med @upstash/ratelimit giver dig production-grade rate limiting i en lille mængde kode.

Et rimelig udgangspunkt: 60 anmodninger per minut for autentificerede brugere, 20 per minut for uautentificerede brugere, og 5 per minut for login/signup-endepunkter (for at forhindre brute forcing).

Tid til at rette: 20–45 minutter.

Fejl 5: Manglende auth-kontroller på beskyttede sider og APIs

Hvordan det sker: AI genererer et smukt dashboard og API-ruter, der returnerer brugerdata, men tilføjer ikke middleware for at verificere brugeren faktisk er logget ind. Siden "fungerer," fordi under udvikling er du altid logget ind. I produktion kan nogen få adgang til dashboard-URL'en direkte uden at logge ind, eller ramme API-endepunktet og få data tilbage.

Hvorfor det er farligt: Uautentificeret adgang til beskyttede sider betyder alle kan se bruger-dashboards, admin-paneler eller private data blot ved at gætte URL'en. Uprotekterede API-ruter betyder ethvert værktøj som Postman eller curl kan hente data uden legitimationsoplysninger.

Hvordan du opdager det: Åbn et inkognito-browservindue (ikke logget ind) og naviger direkte til dine dashboard-, indstillings- eller admin-URL'er. Hvis du kan se noget indhold uden at blive omdirigeret til en login-side, har du dette problem. Prøv derefter at ramme dine API-ruter direkte — hvis de returnerer data uden et gyldigt sessionscookie eller auth-token, er de også uprotekterede.

Løsningen: Tilføj autentificerings-middleware, der kører før alle beskyttede ruter. I Next.js App Router skal du oprette en middleware.ts i dit projektrod:

import { NextResponse } from 'next/server';
import type { NextRequest } from 'next/server';

export function middleware(request: NextRequest) {
  const session = request.cookies.get('session');
  if (!session) {
    return NextResponse.redirect(new URL('/login', request.url));
  }
  return NextResponse.next();
}

export const config = {
  matcher: ['/dashboard/:path*', '/settings/:path*', '/api/protected/:path*'],
};

Tilpas matcher til at dække alle ruter, der kræver autentificering. Test i inkognito efter implementering.

Tid til at rette: 15–30 minutter.

Hvordan du forhindrer disse i fremtidige projekter

Mønstret er klart: AI genererer kode, der fungerer funktionelt, men springer sikkerhed over, fordi du ikke spurgte om det. Løsningen er at spørge om det fra begyndelsen.

Tilføj dette til slutningen af din initiale prompt for ethvert vibe-kodet projekt:

SIKKERHEDSKRAV:
- Alle hemmeligheder i miljøvariabler (aldrig hardkodet)
- Supabase RLS aktiveret på alle tabeller med pr-bruger-politikker
- Server-side inputvalidering på hvert API-endpoint (brug Zod)
- Rate limiting på alle offentlige endepunkter
- Autentificerings-middleware på alle beskyttede ruter
- Ingen service role-nøgle i client-side-kode

Dette vil ikke fange alt, men det eliminerer de fem mest almindelige sårbarheder på første forsøg i stedet for at kræve oprydning senere.

Hvis du ønsker at blive bedre til at skrive prompts, der producerer mere sikker kode fra starten, kan vores gratis prompt-optimering hjælpe dig med at strukturere dine instruktioner. Og for en komplet sikkerhedsvejledning, se vores trin-for-trin-guide: Sådan sikres en vibe-kodet app, før du giver den til klienter.

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