--- title: "Er Supabase trygt? Hva det dekker og hva du må" description: "Supabase er SOC 2 Type 2- og ISO 27001-sertifisert, med kryptering. Om dataene dine er trygge, avhenger av innstillinger bare du styrer." url: "https://madsalt.tech/no/blog/is-supabase-secure/" author: "Denys Zaichenko" language: "no" published: 2026-10-26 --- # Er Supabase trygt? Hva det dekker og hva du må TL;DR Ja, plattformen er trygg: Supabase er SOC 2 Type 2- og ISO 27001-sertifisert, krypterer data i hvile med AES-256 og under overføring med TLS, og signerer HIPAA-avtaler fra Team-planen og oppover. Prosjektet ditt er et annet spørsmål. Under Supabases modell for delt ansvar er tilgangen til tabeller, API-nøkler og auth-innstillinger dine, og plattformen gjør nøyaktig det innstillingene sier. På testtabellen min avgjorde én innstilling om en offentlig nøkkel fikk 0 rader eller alle 3. 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](https://supabase.com/security) og [sikkerhetsdokumentasjon](https://supabase.com/docs/guides/security), 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](https://supabase.com/docs/guides/security/soc-2-compliance) sier det rett ut: Supabases samsvar overføres ikke til noe utenfor Supabases kontroll. ## Hva er din del? Supabases [modell for delt ansvar](https://supabase.com/docs/guides/deployment/shared-responsibility-model) 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: ![Hvem vokter hvert steg i en forespørsel. Supabase driver transporten og nøklene; tilganger og policyer er dine. Fra en nettleser: Nettleser → TLS, key · Supabase → Tilgang · du → RLS · du; Fra serveren din: Server → TLS · Supabase → Secret key · du → RLS hoppes over.](https://madsalt.tech/charts/no/is-supabase-secure.svg) *Figur 1. Basert på Supabases modell for delt ansvar og guiden om API-nøkler, oktober 2026.* 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](https://madsalt.tech/no/blog/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](https://mattpalmer.io/posts/2025/05/statement-on-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](https://supabase.com/changelog/45329-breaking-change-tables-not-exposed-to-data-and-graphql-api-automatically) 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](https://madsalt.tech/no/blog/supabase-october-30-grant-change/). ## 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](https://madsalt.tech/no/tools/supabase-security-check/). 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](https://madsalt.tech/no/blog/lovable-app-security-checklist/). - Hvis appen din har roller og en tilgangsskjerm, bevis at hver tilgangsboks gjør det den sier, som i [hvordan du tester Supabase RLS](https://madsalt.tech/no/blog/how-to-test-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. Vurderer du Supabase til et prosjekt? Utveksler gjerne erfaringer om hva som bør settes opp først. Ingen salgstale. [Ta kontakt](https://madsalt.tech/no/#contact)