Er Supabase trygt? Hva det dekker og hva du må

Jeg er Denys, fullstack- og AI-ingeniør, og de fleste appene jeg bygger eller retter, kjører på Supabase. Klienter spør “er Supabase trygt?” når de egentlig mener “er dataene mine trygge?”. Det er to ulike svar, så denne artikkelen tar dem ett om gangen.

Er Supabase-plattformen trygg?

Plattformsiden er revidert av tredjeparter. Fra Supabases sikkerhetsside og sikkerhetsdokumentasjon, lest 23. oktober 2026:

Kontroll	Hva Supabase oppgir
SOC 2 Type 2	Revideres hvert år; rapporten er tilgjengelig for Team- og Enterprise-kunder
ISO 27001	Sertifisert; sertifikatet er tilgjengelig for Team- og Enterprise-kunder
HIPAA	Støttes med en signert Business Associate Agreement og HIPAA-tillegget, Team-planen og oppover
Kryptering	AES-256 i hvile, TLS under overføring; tilgangstokens og nøkler krypteres også på applikasjonsnivå
Sikkerhetskopier	Daglig for betalte prosjekter; Point in Time Recovery som tillegg fra Pro-planen
Dataplassering	Database, Auth og Storage blir i AWS-regionen du velger

Ingenting av dette beskytter en tabell du har latt stå åpen. SOC 2-guiden sier det rett ut: Supabases samsvar overføres ikke til noe utenfor Supabases kontroll.

Hva er din del?

Supabases modell for delt ansvar lister det som alltid er ditt: kontoen din, tilgangsstyring for databasen og tabellene i den, dataene dine og det å anvende sikkerhetskontroller, inkludert advarslene Security Advisor reiser. I praksis betyr det fire lag med innstillinger:

1. Hvem som kan røre en tabell. Tilganger (grants) avgjør om anon og authenticated i det hele tatt når en tabell. RLS-policyer avgjør hvilke rader.
2. Hvilken nøkkel som hører hvor. Publishable key er offentlig av design, secret key omgår RLS. Jeg sammenlignet dem i Supabase anon key vs service role key.
3. Auth-innstillinger. E-postbekreftelse, leaked password protection (Pro-planen og oppover), minste passordlengde, MFA, redirect-URL-er, CAPTCHA.
4. Alt rundt databasen. Storage-buckets og policyene deres, SECURITY DEFINER-funksjoner, Edge Functions som bruker secret key, og hvilke skjemaer Data API-et eksponerer.

Hvor mye endrer én innstilling?

Jeg kjørte den samme forespørselen mot én tabell med tre falske bestillinger på en lokal Supabase-stack (CLI 2.109.1, Postgres 17.6, PostgREST 14.14), med publishable key, slik en nettleser ville gjort:

Innstilling på tabellen	Hva den offentlige nøkkelen fikk
RLS av	Alle 3 rader, og en insert ga 201 Created
RLS på, ingen policy	[]
RLS på, policy using (true)	Alle 3 rader
Ingen tilgang for anon	42501 permission denied

Samme plattform, samme kryptering, samme sertifiseringer. Forskjellen er én linje SQL. Derfor er en “trygg plattform” og en lekk app ingen motsigelse: CVE-2025-48757 fant 170 av 1 645 Lovable-showcase-apper som ga data til den offentlige nøkkelen, alle på den samme reviderte plattformen.

Blir Supabase tryggere som standard?

Ja, i steg. Supabases changelog fra 28. april 2026 lister en bryter for RLS på som standard, et merke for Data API-eksponering, detaljerte tilganger per tabell og en begrensning på oppslag av skjemaer. Den største kommer 30. oktober 2026: nye tabeller i eksisterende prosjekter får ikke lenger Data API-tilganger automatisk, så en glemt tabell returnerer 42501 i stedet for radene sine. Eksisterende tabeller beholder tilgangene sine, så dette fikser ikke noe som allerede står åpent. De gamle nøklene anon og service_role avvikles også innen utgangen av 2026 til fordel for publishable og secret keys; den nye secret key avviser forespørsler fra en nettleser.

Hva mer omleggingen knekker, og hvordan du sjekker prosjektet på forhånd: Supabase 30. oktober: hva som knekker og hvordan sjekke.

Hvordan sjekker du ditt eget prosjekt?

Start med Supabases egen Security Advisor og rett opp hver advarsel. Sjekk deretter det den ikke dekker:

• Kjør den gratis Supabase-sikkerhetssjekken. Den kobler til skrivebeskyttet og vurderer prosjektet mot 46 regler knyttet til OWASP Top 10:2025: RLS, policyer, views, funksjoner, tilganger, storage og auth-innstillinger, med fiks-SQL for hvert funn.
• Test med to brukere i to selskaper. Ingen skanner vet hvilke rader som tilhører hvem; testen står i sikkerhetsjekklisten min for Lovable-apper.
• Hvis appen din har roller og en tilgangsskjerm, bevis at hver tilgangsboks gjør det den sier, som i hvordan du tester Supabase RLS.

Så: Supabase er et trygt sted å lagre data, og det gir deg verktøyene til å holde dem private. Om de forblir private, avgjøres i skjemaet og innstillingene dine.