Sikkerhed i Lovable og Supabase: 9 ting du skal tjekke før lancering

Før du lancerer en app bygget i Lovable, skal du tjekke ni ting, fra Row Level Security og nøgler til login, backup og adgang. Det meste af sikkerheden i Lovable og Supabase afgøres i databasen, ikke i den kode du ser i editoren. Jeg hjælper selv founders med at gøre AI-byggede apps klar til produktion, så tag det i betragtning, når jeg anbefaler dig at få hjælp.

Den korte version: de 9 tjek

Tjek 1-4 afgør oftest om dine data ligger åbent, så start dér. Resten af vejen til rigtige brugere står i min guide til at gøre en AI-bygget app klar til produktion.

Hvorfor databasen er det svage punkt

En Lovable-app taler direkte med Supabase fra brugerens browser med en offentlig nøgle (anon eller publishable), som alle kan finde i din kildekode. Supabase skriver selv i dokumentationen om API-nøgler, at den nøgle er sikker at vise frem, men kun fordi Row Level Security bestemmer hvad den må. Uden RLS kan alle med nøglen læse og skrive i tabellen.

I 2025 scannede sikkerhedsforskeren Matt Palmer 1.645 Lovable-apps og fandt åbne data i 170 af dem. Fundet blev registreret som CVE-2025-48757. Lovable har siden fået en indbygget sikkerhedsscanning før udgivelse, men skriver selv, at den ikke kan garantere fuld sikkerhed. Andre huller finder du i min oversigt over sikkerhedshuller i AI-genereret kode.

Database og nøgler: tjek 1-4

1. Row Level Security er slået til på alle tabeller

Åbn dit Supabase-projekt og gå til Security Advisor. Den markerer tabeller i public-skemaet uden RLS som fejl. Ret dem alle, også dem du tror er ligegyldige.

Gentag tjekket før hver udgivelse, for nye funktioner fra Lovable kan tilføje tabeller. RLS uden regler lukker for alt via API'et, og det er det rigtige udgangspunkt.

2. Reglerne gør det, du tror

Disse fejl opdager du ikke ved at klikke rundt i appen:

• En regel der giver alle indloggede brugere adgang til alle rækker. Når alle kan oprette en konto, betyder "logget ind" bare "alle".
• Regler for oprettelse eller ændring, hvor with check ikke tjekker ejerskab, så en bruger kan gemme rækker i en andens navn.
• En profiltabel med en rolle-kolonne, som brugeren selv må opdatere. Så kan alle gøre sig selv til admin.
• Regler der stoler på user_metadata, som brugeren selv kan redigere.

Testen: opret to testbrugere, log ind som den ene, og prøv at hente, ændre og slette den andens data direkte mod API'et, præcis som en angriber ville. Kan du ikke selv lave testen, er det her en udvikler gør mest gavn.

3. Hemmelige nøgler ligger kun på serveren

Supabases hemmelige nøgle (service_role eller secret) omgår alle RLS-regler. Den må aldrig ligge i frontend, i dit kodearkiv på GitHub eller i Lovables chat. Det samme gælder hemmelige nøgler til Stripe og OpenAI, som hører hjemme i Lovables Secrets-værktøj eller som secrets til en Edge Function.

Åbn din udgivne app med udviklerværktøjerne i Chrome, og søg i alle indlæste filer efter sb_secret, sk_ og sk-. Bruger projektet de ældre nøgler, der starter med eyJ, så sammenlign med API-indstillingerne i Supabase: nøglen i koden skal være anon-nøglen. Finder du en hemmelig nøgle, så skift den med det samme. Den ligger stadig i Git-historikken, selvom du sletter den fra koden.

4. Views og funktioner går ikke uden om reglerne

Et view i Postgres kører som udgangspunkt med ejerens rettigheder og springer dermed RLS over. Supabase anbefaler i guiden til Row Level Security at sætte security_invoker = true på views. Samme problem gælder funktioner markeret security definer i public-skemaet, som kan kaldes via API'et. Security Advisor fanger mange af dem.

Filer og login: tjek 5-6

5. Filer ligger i den rigtige slags bucket

I Supabase Storage kan alle med linket læse filerne i en public bucket. Det er fint til produktbilleder, men ikke til fakturaer, kontrakter eller ID-kort. Private filer skal i en privat bucket med regler, fx at en bruger kun må læse og uploade i en mappe med sit eget bruger-id. Begræns også filtype og størrelse.

6. Login er sat op til rigtige brugere

Supabase Auth kommer med standardindstillinger til udvikling, ikke til lancering:

• Site URL står som udgangspunkt til http://localhost:3000. Skift den til dit domæne, ellers peger bekræftelses- og nulstillingsmails forkert.
• Redirect-adresser skal være præcise i produktion, ikke brede wildcards.
• Den indbyggede mailafsendelse er kun til test og sender kun til dit team, så opsæt din egen SMTP-udbyder.
• Kræv mindst 8 tegn i adgangskoder, og slå beskyttelse mod lækkede adgangskoder til, hvis du er på Pro-planen.
• Er appen kun for inviterede, så slå åben tilmelding fra.

Logik, backup og drift: tjek 7-9

7. Forretningsregler håndhæves på serveren

Alt i frontenden kan brugeren ændre. Tjekker din app kun i React-koden om brugeren har betalt eller har kreditter tilbage, kan man springe tjekket over ved at kalde API'et direkte. Flyt reglerne ned i databasen (constraints og RLS) eller i en Edge Function. Betalingsstatus må kun ændres af en webhook fra fx Stripe med verificeret signatur.

8. Backup er slået til, og du har prøvet at gendanne

Ifølge Supabases dokumentation om backup har gratisplanen ingen automatiske backups. Pro giver daglige backups i 7 dage, Team i 14. Point-in-Time Recovery (gendannelse til et bestemt tidspunkt) er et tilkøb fra ca. 100 dollars om måneden. Filer i Storage er ikke med i backuppen, og en gendannelse giver nedetid.

Min tommelfingerregel: har du betalende kunder eller data du ikke kan genskabe, så vær mindst på Pro, og prøv en gendannelse i et separat projekt. På Lovable Cloud finder du backup og gendannelse under Database i Lovable.

9. Adgang, ejerskab og overvågning

• Slå to-faktor til på Lovable, Supabase, GitHub, Stripe og dit domæne, og del ikke logins.
• Synkronisér koden til GitHub, så du ejer den uden for Lovable.
• Hav et separat testprojekt, for Lovable ændrer databasen i det projekt, appen er koblet til.
• Har du europæiske brugere, så vælg en EU-region, når projektet oprettes.
• Kig i Supabases logs den første uge efter lancering.

Kan du klare det selv?

Ja, hvis appen er lille. Med få tabeller, ingen betaling og ingen følsomme data kommer du langt med Security Advisor, Lovables scanning og to testbrugere.

Få hjælp, hvis appen har betaling, teams med forskellige roller eller personoplysninger som helbred og økonomi. Her er fejlene sjældent synlige i en scanning. Mine 10 tegn på at det er tid til at hyre en udvikler hjælper dig med at vurdere det.

Og det ærlige modsvar: tester du en prototype med opdigtede data, så brug pengene på at finde ud af, om nogen vil have produktet, ikke på en sikkerhedsgennemgang. Holder fundamentet ikke, så se min beslutningsguide om at genskrive eller redde din AI-app.

Næste skridt

1. Kør Security Advisor og Lovables scanning, og ret alt markeret som fejl eller kritisk.
2. Test reglerne med to brugere, og tjek at kun offentlige nøgler ligger i frontenden.
3. Slå backup til, og gå resten af tjeklisten igennem før du åbner for tilmelding.

Vil du have en udvikler med på de sidste skridt, kan du se hvordan jeg arbejder med at få AI-byggede apps sikkert i produktion. Du taler direkte med mig, og du ejer koden fra dag ét.

Ofte stillede spørgsmål

Er Lovable sikkert nok til en app med betalende kunder?+

Ja, men kun hvis den er sat rigtigt op. Lovable og Supabase giver dig byggeklodserne: RLS, login, secrets og backup. Med betaling og persondata anbefaler jeg, at en udvikler gennemgår regler, nøgler og webhooks før lancering og igen efter større ændringer.

Gælder tjeklisten også for Lovable Cloud og Bolt?+

Ja, langt hen ad vejen. Lovable Cloud er bygget på Supabase, så de samme principper gælder, selvom indstillingerne ligger i Lovable i stedet for i Supabases dashboard. Bygger du med Bolt eller et andet værktøj oven på Supabase, gælder alle ni punkter.

Hvad gør jeg, hvis data har ligget åbent?+

Luk hullet først: slå RLS til eller stram reglerne, og skift alle nøgler, der kan være lækket. Tjek derefter hurtigt Supabases logs, da de kun gemmes i en begrænset periode. Har personoplysninger været tilgængelige for uvedkommende, kan du efter GDPR have pligt til at anmelde bruddet til Datatilsynet inden for 72 timer. Tal med en juridisk rådgiver om din konkrete situation.