Et eftersyn af AI-genereret kode skal svare på tre spørgsmål, før I åbner for kunder: kan én kunde nå en anden kundes data, ligger der hemmelige nøgler, hvor uvedkommende kan læse dem, og hvad sker der, hvis nogen bruger appen på en anden måde end tiltænkt? AI-værktøjer laver sjældent de samme fejl som mennesker. De bygger det, I beder om, og lader ofte det stå åbent, I ikke bad om at få lukket. Denne artikel beskriver svaghederne, så I som stifter kan stille de rigtige spørgsmål. Det er generel viden om, hvad en menneskelig gennemgang bør dække.
Hvorfor en app kan se færdig ud og stå pivåben
En webapp består af to dele. Frontend er det, der kører i brugerens browser. Backend er det, der kører på serveren og i databasen. Alt i frontend kan læses og ændres af brugeren, også selv om det ikke vises på skærmen.
AI-byggede apps lægger ofte meget logik i frontend, fordi det giver hurtige resultater. En skjult knap ligner en beskyttelse. Den, der kan bruge browserens udviklerværktøjer, kan alligevel kalde funktionen bag knappen direkte. Værktøjet tester desuden mod det, I har bedt om. I bad om, at en administrator kan se alle kunder. I bad sjældent om, at alle andre ikke kan.
Svaghed 1: Adgangskontrol i browseren
Reglen er, at hver handling skal kontrolleres på serveren. Tegn på problemet:
- Hvem der er administrator, afgøres af en værdi, browseren sender med.
- Siden til administratorer er blot skjult i menuen.
- Et kunde-id i adressen kan ændres, hvorefter en anden kundes side vises.
Den første prøve kræver ingen teknisk baggrund. Opret to konti, log ind med den ene, kopier adressen på en side med data, og åbn den, mens I er logget ind med den anden. Virker det, har I et alvorligt fund. Går prøven godt, viser det kun, at netop dén side er i orden.
Svaghed 2: Databaseregler genereret af AI
Mange app-byggere bruger en database, som browseren taler direkte med. Så er databasens egne regler det eneste værn. I databasen Postgres, som blandt andet Supabase bygger på, hedder funktionen rækkesikkerhed eller row level security: regler, der for hver række afgør, hvem der må læse og ændre den. Reglerne skal være slået til på hver tabel, og de skal være rigtige. Supabases dokumentation advarer om, at en regel kan være formuleret, så alle rækker bliver synlige, og at hemmelige nøgler går uden om reglerne helt.
Spørg derfor den, der gennemgår koden:
- Er reglerne slået til på alle tabeller, også de nyeste?
- Er der nogen regel, der i praksis tillader alt?
- Må en bruger ændre rækker, der tilhører andre, eller sætte sig selv som administrator?
- Hvad kan en besøgende uden login?
Nogle værktøjer har et indbygget sikkerhedstjek. Bolt oplyser i sin hjælp, at tjekket dækker databasen og ikke hele projektet. Brug den slags tjek som hjælp, og betragt dem som et første filter.
Svaghed 3: Nøgler i frontend
Der findes offentlige nøgler, der godt må ligge i browseren, når reglerne bag dem er i orden, og hemmelige nøgler, der aldrig må. Forskellen kan være svær at se for en, der ikke koder, og AI-værktøjer blander dem af og til sammen.
Ligger en hemmelig nøgle i den kode, browseren henter, skal den betragtes som kompromitteret, altså kendt af uvedkommende. Det samme gælder nøgler, der har ligget i et offentligt repository, også selv om de senere er fjernet, for historikken gemmer dem. Løsningen er at udskifte nøglen og flytte kaldet over på serveren. Kig også på nøgler til AI-tjenester og betaling, hvor misbrug hurtigt bliver dyrt. Se nøgler og adgangskoder i koden.
Svaghed 4: Det, ingen bad om
Listen kan gøres lang, og disse punkter går igen:
- Filer. Kan uploadede filer hentes af alle, der kender adressen?
- Input. Kontrolleres det, brugeren skriver, på serveren?
- Begrænsninger. Kan nogen prøve tusindvis af adgangskoder eller sende tusindvis af kald?
- Afhængigheder. Hvilke biblioteker er trukket ind, findes de overhovedet, og er de opdaterede?
- Fejlbeskeder. Afslører de tekniske detaljer om appen?
Hvad en menneskelig gennemgang skal svare på
Som generel viden bør en gennemgang før lancering resultere i klare svar:
- Hvordan håndhæves adskillelsen mellem kunder, og er den prøvet i praksis?
- Hvor ligger alle nøgler, og hvilke er udskiftet?
- Hvilke fund er alvorlige nok til at standse lanceringen?
- Hvilke fund kan vente, og hvornår rettes de?
- Hvilke dele er ikke gennemgået?
Det sidste punkt fortjener opmærksomhed. En gennemgang er en læsning af koden. En penetrationstest, ofte kaldet pentest, er noget andet: en fagperson forsøger med jeres tilladelse at bryde ind i den kørende app. Har I følsomme data, eller kræver kunderne det, kommer testen oven i. Hvad en sådan test skal munde ud i, kan I læse mere om på pentestrapport.dk, og det forarbejde, produktet har brug for, står i før kunden kræver en pentest. De tal for sårbarheder i AI-kode, der cirkulerer, kommer ofte fra firmaer med noget på hylden, så lad jeres egne fund styre prioriteringen.
Gentag øvelsen, når der kommer større ændringer. En app, der fortsat bygges med AI, kan miste en regel, som var i orden i sidste uge.
Det skal I lade være med
· At nøjes med at bede samme AI om at vurdere sin egen kode. Det kan finde noget, og det erstatter ikke en uafhængig læsning.
· At teste med én konto. De alvorligste fejl viser sig først med to kunder.
· At fjerne en nøgle uden at udskifte den. Den er stadig gyldig.
· At åbne for kunder med et uafklaret, alvorligt fund. Luk appen eller funktionen, til fundet er rettet.
Det skal I kræve af den eksterne
- ☐ En skriftlig liste over fund, prioriteret efter alvor og forklaret uden fagord.
- ☐ Klar besked om, hvad der er gennemgået, og hvad der ikke er.
- ☐ Bevis på, at kundeadskillelsen er prøvet med mindst to konti.
- ☐ Et overblik over nøgler og over, hvilke der er udskiftet.
- ☐ En vurdering af, om der også er brug for en pentest.
Kilder
- Supabase: Row Level Security: hvordan reglerne virker, og hvad hemmelige nøgler kan. Læst november 2026.
- Bolt: Database: omfanget af det indbyggede sikkerhedstjek. Læst november 2026.
Senest gennemgået: november 2026.
Næste skridt
Læs også: Persondata i produktet · Sikker softwareudvikling i et lille team
→ Kontakt · Tlf. 70 13 63 23 · Ekstern CTO hos Nielco IT
