Er det farligt at lancere en app, der er bygget med AI?

Ikke i sig selv. AI-værktøjer skriver ofte udmærket kode til det, man kan se på skærmen. Problemerne ligger typisk i det, man ikke kan se: adgangskontrol i databasen, hemmelige nøgler, fejlhåndtering og backup. Det er de ting, der bør gennemgås, før rigtige brugere lægger data i systemet.

Hvordan ser jeg, om min Supabase-database er åben for alle?

Åbn Table Editor i Supabase og se, om der står 'RLS disabled' på dine tabeller. Hvis Row Level Security er slået fra, kan enhver med din offentlige nøgle — som ligger i din frontend — læse og ændre alle rækker. Er RLS slået til, skal du stadig tjekke, at dine policies faktisk begrænser adgangen til brugerens egne data.

Skal koden skrives om, eller kan den reddes?

Som regel kan den reddes. Det meste vibecodede kode har en brugbar brugerflade og en datamodel, der kan arbejdes videre med. En omskrivning giver først mening, når sikkerheden er bygget forkert ind i fundamentet, eller når hver ny ændring vælter noget andet.

Kan jeg selv rette tingene med AI?

En del af dem, ja — især hvis du ved, hvad du skal bede om. Tjeklisten her er skrevet, så du kan bruge den som udgangspunkt. Det svære er at vide, om rettelsen faktisk virker: en AI siger gerne, at RLS nu er sat korrekt op, uden at det passer. Dér er det en fordel at få en erfaren udvikler til at efterprøve det.

Er din vibecodede app klar til rigtige brugere? 8 ting at tjekke, før du går live

Du har bygget noget, der virker. Måske med Lovable, Bolt, v0 eller Cursor — og måske uden at have skrevet en linje kode selv. Det er imponerende, hvor langt man kan komme.

Men "det virker, når jeg prøver det" og "det er klar til rigtige brugere" er to forskellige ting. AI-værktøjer er gode til det, du kan se på skærmen. De er markant dårligere til det, du ikke kan se — og det er netop dér, det går galt, når fremmede begynder at bruge din app.

Her er de otte ting, jeg altid tjekker først.

1. Er din database åben for alle?

Det her er den mest almindelige og mest alvorlige fejl i apps bygget oven på Supabase, som mange AI-værktøjer vælger som standard.

I Supabase taler din frontend direkte med databasen ved hjælp af en offentlig nøgle. Det er helt efter bogen — men kun hvis Row Level Security (RLS) er slået til og sat rigtigt op. RLS er de regler, der bestemmer, hvilke rækker en given bruger må se og ændre.

Sådan ser det ud, når to af tre tabeller står åbne. Det er det første, jeg kigger efter.

Er RLS slået fra, kan enhver, der åbner browserens udviklerværktøjer, finde din offentlige nøgle og hente alle rækker i alle tabeller. Også de andre brugeres.

Sådan tjekker du det: Åbn Table Editor i Supabase. Står der "RLS disabled" ud for en tabel, er den åben. Står der "RLS enabled", så åbn policies og læs dem: en policy med betingelsen true giver stadig alle adgang.

2. Ligger der hemmelige nøgler i din frontend?

Der findes to slags nøgler: dem, der gerne må være offentlige, og dem, der aldrig må. Supabases anon-nøgle er lavet til at ligge i browseren. Det er service_role-nøglen, din OpenAI-nøgle og din Stripe secret key ikke.

Tommelfingerregel: kan nøglen bruges til at læse alt eller koste penge, hører den hjemme på serveren.

Alt, hvad der ligger i din frontend-kode, kan læses af alle. Også selvom det står i en .env-fil: variabler med præfikset NEXT_PUBLIC_ eller VITE_ bliver bagt ind i den JavaScript, browseren henter.

Sådan tjekker du det: Åbn din side, åbn udviklerværktøjerne, og søg i de hentede JavaScript-filer efter sk-, service_role og secret. Finder du noget, skal nøglen udskiftes med det samme — ikke bare flyttes. Den er allerede lækket.

En lækket OpenAI-nøgle er i øvrigt ikke kun et sikkerhedsproblem. Det er en regning, andre kan køre op for dig.

3. Tjekker serveren, hvem der spørger?

AI-genereret kode skjuler ofte ting i brugerfladen i stedet for at beskytte dem. Admin-knappen vises kun for administratorer — men det endpoint, knappen kalder, tjekker ikke, om den, der kalder, faktisk er administrator.

At skjule en knap er brugervenlighed. Sikkerheden ligger i de to led til højre.

Reglen er enkel: alt, der sker i browseren, kan omgås. Enhver kontrol, der betyder noget, skal ske på serveren eller i databasens regler.

Sådan tjekker du det: Find de handlinger i din app, der ikke må kunne udføres af alle — slet, rediger, se andres data, admin-funktioner. Undersøg for hver af dem, hvor kontrollen ligger. Ligger den kun i en if i en React-komponent, er den ikke en kontrol.

4. Hvad sker der, når noget går galt?

Prøv at slå dit netværk fra midt i en handling. Send en formular med tomme felter. Upload en fil på 200 MB. Skriv en emoji i et talfelt.

Vibecodede apps er typisk bygget til den glade vej: brugeren gør det rigtige, og alt svarer. Rigtige brugere gør alt muligt andet, og så får de en hvid skærm, en evig spinner — eller værre: en handling, der blev udført halvt.

Sådan tjekker du det: Brug ti minutter på at være en besværlig bruger. Notér alt, der ender i en blank side eller en teknisk fejlbesked. Tjek også, at du selv får besked, når noget fejler i produktion — ellers hører du det først fra en kunde.

5. Har du en backup — og har du prøvet den?

Spørg dig selv: hvis alle data i din database forsvandt i aften, hvad ville du så gøre i morgen?

Gratis-planer hos de fleste databaseudbydere har enten ingen automatisk backup eller kun få dages historik. Og en backup, man aldrig har prøvet at gendanne fra, er en formodning, ikke en backup.

Sådan tjekker du det: Find ud af, hvilken backup din plan faktisk giver dig, og hvor langt tilbage den rækker. Lav et manuelt udtræk af databasen, før du går live, og gem det et andet sted end hos udbyderen.

6. Kan nogen køre en regning op for dig?

Hvis din app kalder en betalt tjeneste — en sprogmodel, SMS-afsendelse, e-mail, billedgenerering — så er hvert kald penge. Uden begrænsninger kan en enkelt person eller et script sende tusindvis af kald på en eftermiddag.

Illustration: uden et loft er det dit kreditkort, der finder ud af, at nogen har fundet din nøgle.

Sådan tjekker du det: Kræver de dyre funktioner, at man er logget ind? Er der et loft over, hvor mange kald én bruger kan lave? Har du sat en forbrugsgrænse og en alarm hos udbyderen? Det sidste tager fem minutter og er den billigste forsikring, du kan købe.

7. Overholder du reglerne for persondata?

Så snart du gemmer en e-mailadresse, behandler du persondata, og så gælder GDPR — også for et lille sideprojekt. Det er sjældent noget, et AI-værktøj tænker på af sig selv.

Minimum er, at du ved, hvilke data du gemmer og hvorfor, at du har en privatlivspolitik, der fortæller det, at brugere kan få deres data slettet, og at du har styr på, hvor dine data fysisk ligger. Mange tjenester lader dig vælge en region i EU — men kun hvis du husker at vælge den, når projektet oprettes.

Sætter du cookies til statistik eller markedsføring, skal du desuden have et samtykke, før de sættes.

8. Ejer du selv det, du har bygget?

Det sidste punkt handler ikke om sikkerhed, men om frihed. Ligger din kode kun inde i det værktøj, du byggede den i? Kører din side på værktøjets eget underdomæne? Er databasen oprettet på en konto, du ikke selv styrer?

Så er du afhængig af, at værktøjet bliver ved med at eksistere, bliver ved med at koste det samme og bliver ved med at kunne det, du har brug for.

Sådan tjekker du det: Sørg for, at koden ligger i dit eget GitHub-repository, at siden kører på dit eget domæne, og at database og hosting står i dit eget navn. Så kan du til enhver tid tage projektet med dig — til en anden udvikler, et andet værktøj eller en anden hosting.

Hvad så nu?

Gennemgå listen ærligt. Er der ét eller to punkter, du er usikker på, kan du ofte selv komme i mål — brug gerne listen som udgangspunkt for dine prompts.

Er der flere, eller ligger der allerede rigtige brugeres data i systemet, er det en god idé at få en erfaren udvikler til at se det igennem. Ikke for at skrive det hele om, men for at finde de huller, der betyder noget, og lukke dem ordentligt.

Det er præcis den slags, jeg hjælper med. Læs mere om eksperthjælp til vibecodede projekter, eller skriv til mig, så tager vi en uforpligtende snak om dit projekt.