TechCrunch rapporterer, at “some Supabase customers are publicly exposing reams of people’s data to the web” og peger på, at “AI-generated and vibe-coded apps can spill and expose users’ data when not configured or secured properly.” Begge citater er deres ord. Samtidig hævder UpGuard i en ny analyse at have identificeret cirka 16.000 eksponerede Supabase-databaser. Hvis tallet holder, er omfanget markant.
Hvad betyder det i praksis? At fejlkonfigurerede backends – især når de spindes op af skabeloner, scripts eller AI-assisterede værktøjer – kan gøre data offentligt tilgængelige uden et egentlig brud på firewallen. Ikke en zero-day, men for brede policies, offentlige tabeller og oversete tokens. Resultatet: persondata i fri sigt.
Hvad TechCrunch fandt
TechCrunchs artikel fra 25. september 2026 dokumenterer fund, hvor nogle Supabase-kunder – ikke Supabase som produkt – har gjort store datamængder offentlige. Formuleringen “publicly exposing reams of people’s data” dækker over forkert adgangskontrol og åbne endepunkter. Artiklen fremhæver også, at AI-genererede og “vibe-coded” apps hæver tempoet, men ofte uden tilsvarende sikkerhedsmodenhed.
TechCrunch navngiver ikke specifikke kunder og viser ikke datasæt. Det begrænser verifikation for læsere, men ændrer ikke ved, at risikoen er velkendt på platforme med lav friktion. Der er ingen påstand om en produktfejl i Supabase-kerne – det er brug og konfiguration, der halter.
UpGuard-tallet 16.000 databaser
UpGuard skriver, at de har fundet “around 16,000 databases” eksponeret på Supabase og beskriver en systemisk eksponeringsrisiko knyttet til konfiguration. De peger på et forløb siden 2025, hvor misconfigurations er tilbagevendende. Det naturlige spørgsmål er derfor metodik: hvordan måles der, og hvad tæller som “eksponeret”.
Hvad er konkret eksponeret
Der er endnu ikke offentliggjort verificerede eksempler på konkret misbrug eller dataudtræk fra netop disse instanser. Fravær af bevis er ikke bevis for fravær – men retorikken bør afspejle, at dokumentation for faktisk skade ikke er lagt frem.
Hvorfor AI-genererede og vibe-coded apps er sårbare
Hastighed og skabeloner frister. Når AI-værktøjer og kodeassistenter leverer et helt CRUD-lag på få minutter, er det nærliggende at lade dev-defaults glide med i prod. Her kan policies i Supabase – især Row Level Security, anonyme nøgler, offentlige tabeller og realtime-kanaler – ende forkert. Ikke fordi værktøjet vil det, men fordi automatiske valg får lov at blive stående.
Miljø-separation er en anden klassiker: en offentlig nøgle eller et testskema fra staging ender i produktion. Eller en Edge Function, tænkt som en hurtig intern prøve, lever videre bag et for slapt CORS-setup. Små fejl summerer hurtigt til stor risiko.
Det tekniske i øjenhøjde
I Supabase består sikkerheden i praksis af flere lag: projektets API-nøgler, Postgres-roller, RLS-policies, storage-buckets og konfiguration af offentlige endepunkter. En åben bucket med logfiler kan indeholde personhenførbare oplysninger, selv hvis tabellerne er låst. En enkelt policy, der bruger OR i stedet for AND, kan åbne rækkevisninger på tværs af brugere. Let at overse, når tempoet er højt.
Fejl går også igen i deploy-scripts: Terraform-moduler eller CLI-templates, der ikke spørger eksplicit til RLS on\/off, eller scripts der ikke markerer rødt, hvis en public-rolle får write. Når mønstre klones i mange projekter, vokser angrebsfladen – ikke på grund af én stor sårbarhed, men mange små.
Supabase og ansvarslinjen
Konfiguration er kundens ansvar, men platforme kan reducere sandsynligheden for fejl. Gode defaults, tydelige advarsler og guided onboarding hjælper. Ifølge offentlige dokumentation og changelogs sker der løbende forbedringer, men en samlet tidslinje for tiltag mod netop disse misconfigurations er ikke fremlagt side om side med UpGuards fund.
Compliance og de tørre krav
Konsekvenserne rækker ud over myndigheder. Kontraktlige forpligtelser – især i finans, sundhed og enterprise SaaS – kan være skrappere end lovgivningen. Ét åbent endpoint kan udløse brud på SLA’er og sikkerhedsbilag. Renommeet tager skade, og det stjæler fokus fra produktet.
Drift og overvågning i hverdagen
Tre greb gør forskellen. 1) Automatiske scans af offentlige endepunkter og metadata på tværs af konti – ikke kun per projekt. 2) Policy-tests i CI, der bryder build, hvis RLS mangler på tabeller med persondata. 3) Regelmæssig rekognoscering af åbne buckets og anonyme nøgler. Ikke fancy – bare konsekvent.
En monitor er ikke nok. Ejerskab skal være entydigt, så nogen alarmeres, når et projekt afviger fra baseline. Tænk change management som kode: hvis en developer slår public læseadgang til, skal det logges, reviewers skal se det, og ændringen skal rulles tilbage, hvis testen fejler.
Tre tekniske trin at tage nu
Her er en kort liste, inspireret af et rådgivningsnotat om AI-projekter og driftssikkerhed. Den er ikke dokumentation for eksponeringen, men en praktisk start: 1) Indfør en CI-regel, der kræver eksplicit RLS på alle tabeller med persondata, plus en test der forsøger uautoriserede SELECT\/INSERT fra public. 2) Kør ugentlige scans efter åbne Supabase-endepunkter, storage-buckets og anonyme nøgler, og alarmér uden for arbejdstid. 3) Adskil dev, staging og prod i hver sin konto\/organisation, og forbyd brug af anonyme nøgler i prod via en platform-policy.
Hvis organisationen bruger AI-kodeassistenter eller auto-genererede scaffolds, så tilføj et pre-commit hook, der scanner for farlige defaults i de mest brugte skabeloner. Og slå “public by default” fra, hvor det er muligt.
Onboarding hos leverandører og low-code platforme
Platforme som Supabase kan sænke risikoen med mere opinionated onboarding. Tænk “tvangsquiz”: før et projekt kan gå live, skal operatøren bekræfte, at RLS er aktiveret på relevante tabeller, at anonyme nøgler ikke bruges i prod, og at storage-buckets med persondata er private. Det føles formynderisk – netop pointen.
Bedre defaults hjælper også. Hvis nye tabeller starter med RLS on, og ingen roller har adgang, før en policy sættes, bliver den sikre vej den nemme. Eksempelskabeloner bør vise secure-by-default patterns frem for hurtige demoer med åbne endepunkter. Værktøjsstøtte vinder i en travl hverdag.
Usikkerheder og åbne spørgsmål
Der er stadig huller i historien: Hvilke virksomheder står bag de eksponerede instanser, og hvilke datakategorier lå åbent? Hvor længe stod de åbne, og er der bevis for misbrug? UpGuards metode og falsk-positiv-rate er ikke fuldt belyst. Det samme gælder Supabases egen tidslinje for opdateringer og eventuelle kundeadvarsler.
Næste skridt er jordnære: få metodik ud fra UpGuard, en officiel kommentar fra Supabase og et par verificerede, anonymiserede kundecases med tidspunkter og datatyper. Indtil da er det klogt at handle, som om eksponeringen kan ske hos enhver, der har skubbet kode hurtigt i mål.
Hvorfor det her betyder noget nu
AI- og low-code-bølgerne har gjort ideer billige at teste. Det er godt. De har også gjort det let at lave fejl i fuld fart. Pointen er ikke, at nye værktøjer nødvendigvis lækker data, men at tempo uden sikkerhedsvaner koster – ofte midt i en kundedialog eller under en revision.
Konklusionen er prosaisk: Sæt fart på produktet, men bind sikkerheden fast i pipeline og værktøjer. Policies skal være testbare, målbare og umulige at overse – før det er Datatilsynet, der gør opmærksom på dem.
