Alle indlæg
Sikkerhed · 5 min. læsning

AI byggede din app på en weekend. Her er de 6 sikkerhedshuller, den glemte.

Apps bygget med AI virker fra dag ét - men “få det til at virke” er ikke det samme som “gør det sikkert”. Efter forårets Vercel-breach og Alibabas rogue agent er naivitet ikke længere en mulighed. Her er de seks huller, jeg oftest ser i AI-byggede apps - og hvordan du lukker dem alle på én aften.

Der har aldrig været et bedre tidspunkt at bygge software på - og aldrig et værre tidspunkt at lade den stå ulåst. AI står nu på begge sider af kampen: Den hjælper dig med at shippe på en weekend, og den hjælper angribere med at scanne, teste og udnytte i en skala, intet menneskeligt team nogensinde kunne.

Foråret gjorde det konkret. Vercel - en af de mest betroede platforme i webudvikling - blev kompromitteret gennem et AI-værktøj i deres egen supply chain, og kundernes miljøvariabler endte dekrypterede og til salg. Omtrent samtidig forvandlede en AI-agent hos Alibaba i al stilhed firmaets servere til en crypto-miner og gravede sig en bagdør ud af sin sandbox. Ingen havde bedt den om det.

Imens finder automatiserede scannere splinternye domæner inden for få timer efter launch. Lille betyder ikke usynlig - det betyder bare uforsvaret.

Problemet ved at bygge hurtigt er, at AI skriver præcis det, du beder om. Du beder om features, og den leverer den glade sti. Sikkerhed er den del, ingen beder om - så det er den del, ingen får.

Det her indlæg er den tjekliste, der burde følge med enhver AI-bygget app: seks almindelige huller, i almindeligt sprog, hver med en løsning du selv kan klare.

1. Dine API-nøgler ligger ikke der, hvor du tror

Åbn din app i browseren, tryk F12, og kig dig omkring. Alt, hvad din frontend-kode indeholder - hver nøgle, hver URL, hver “skjult” admin-rute - ligger lige der, læsbart for enhver, der gider kigge. Starter en miljøvariabel med NEXT_PUBLIC_ eller VITE_, er den offentlig pr. definition. Betalingsnøgler, AI-nøgler og admin-hemmeligheder hører hjemme på serveren, bag et endpoint du kontrollerer. Og har en nøgle nogensinde rørt klientkode eller et offentligt repo, så lad være med at diskutere det med dig selv: Rotér den i dag.

2. Din database siger ja til alle

Supabase er genialt til at bygge hurtigt, og den offentlige anon-nøgle er sikker by design - men kun hvis Row Level Security er slået til. Uden RLS kan den offentlige nøgle læse og redigere hver eneste række i hver eneste tabel: alle brugere, alle ordrer, alle private beskeder. Slå RLS til på samtlige tabeller, skriv policies der siger “brugere ser kun deres egne rækker”, og test det så, som en fremmed ville - logget ud, bevæbnet med intet andet end anon-nøglen. Det er den mest almindelige lækage i AI-byggede apps, og løsningen koster én aften.

3. Stol aldrig på noget, browseren sender

Browseren er fjendeland. Priser, antal, bruger-ID'er og isAdmin-flag fra klienten kan alle redigeres, før de når frem til dig - at ændre en pris fra 499 til 1 i en checkout-request tager ti sekunder i DevTools. Reglen er enkel: Klienten spørger, serveren bestemmer. Genberegn priser på serveren, slå roller op i databasen, og validér hvert input mod et skema, før det rører noget, der betyder noget.

4. Login er ikke det samme som sikkerhed

At skjule en knap er ikke sikkerhed - ruten bag den findes stadig. Hver API-rute, server action og side, der rører private data, skal selv tjekke sessionen, hver eneste gang. Og lad ikke AI bygge dig et hjemmestrikket login-system. Brug noget gennemprøvet som Supabase Auth, Clerk eller NextAuth, og brug i stedet din energi på tjekkene rundt om det.

5. Bots finder dig, før dine kunder gør

Nye domæner bliver scannet inden for få timer efter launch. Trafikken er automatiseret, tålmodig og fuldstændig ligeglad med, hvor lille du er. Minimumsudstyret ser sådan ud:

  • Rate limiting på login, signup og password reset - brute force er et talspil, så gør tallene dårlige
  • En moderne CAPTCHA som Cloudflare Turnstile på offentlige formularer, så din kontaktformular ikke bliver en spam-kanon
  • Hårde grænser på alt, der koster penge - især AI-endpoints, hvor en åben rute betyder, at andres chatbot kører på dit kreditkort
  • Alarmer ved unormalt forbrug, så du opdager det på en graf i stedet for på en faktura

6. Vercel-lektionen: Din supply chain er en del af din app

Vercel-breachet startede ikke hos Vercel - det startede i et værktøj i deres supply chain. Din er mindre, men har præcis samme form: Hver pakke, du installerer, kører med fuld tillid inde i din app. Hold dine dependencies få og kedelige, commit din lockfile, kør en audit i ny og næ, og tænk dig om to gange, før du paster noget ind i AI-værktøjer - inklusive logs og .env-filer fulde af hemmeligheder. Giv hver token mindst mulig adgang, så en lækage forbliver en lille lækage.

Tjeklisten til én aften

  • Ingen hemmeligheder i klientkode eller git-historik - rotér alt, der nogensinde er lækket
  • Row Level Security slået til på hver tabel, testet mens du er logget ud
  • Hver API-rute og server action tjekker sessionen - ikke kun brugerfladen
  • Alt input valideres på serveren; priser og roller kommer aldrig fra klienten
  • Rate limits på login og på alt, der koster penge pr. request
  • Turnstile eller lignende på hver offentlig formular
  • Dependencies få og opdaterede, lockfile committet
  • Backups, du rent faktisk har prøvet at gendanne én gang
Apps bliver sjældent hacket af genier. De bliver hacket af bots, der prøver dørhåndtag - tjeklisten er bare dig, der låser dine døre.

Gør det i aften

Intet af det her kræver et sikkerhedsteam. Det er én aften med ucharmerende arbejde - og det er forskellen på en dårlig morgen og en, der lukker forretningen. Din app står allerede på de lister, bots crawler. Det eneste spørgsmål er, om håndtaget drejer, når de prøver.