--- title: "Er Supabase sikkert? Hvad det dækker, og hvad du må" description: "Supabase er SOC 2 Type 2- og ISO 27001-certificeret, med kryptering i hvile og under transport. Om dine data er sikre, afhænger af indstillinger, kun du styrer." url: "https://madsalt.tech/da/blog/is-supabase-secure/" author: "Denys Zaichenko" language: "da" published: 2026-10-26 --- # Er Supabase sikkert? Hvad det dækker, og hvad du må TL;DR Ja, platformen er sikker: Supabase er SOC 2 Type 2- og ISO 27001-certificeret, krypterer data i hvile med AES-256 og under transport med TLS og underskriver HIPAA-aftaler fra Team-planen og opefter. Dit projekt er et andet spørgsmål. Efter Supabases model for delt ansvar er adgang til tabeller, API-nøgler og auth-indstillinger dine, og platformen gør præcis det, de indstillinger siger. På min lokale testtabel afgjorde én indstilling, om en offentlig nøgle fik 0 rækker eller alle 3. Jeg er Denys, fullstack- og AI-ingeniør, og de fleste apps, jeg bygger eller retter, kører på Supabase. Klienter spørger "er Supabase sikkert?", når de mener "er mine data sikre?". Det er to forskellige svar, så denne artikel tager dem et ad gangen. ## Er Supabase-platformen sikker? Platformssiden bliver auditeret af tredjepart. Fra Supabases [sikkerhedsside](https://supabase.com/security) og [sikkerhedsdokumentation](https://supabase.com/docs/guides/security), læst 23. oktober 2026: | Kontrol | Hvad Supabase angiver | | ------------- | -------------------------------------------------------------------------------------------------------- | | SOC 2 Type 2 | Auditeres hvert år; rapporten er tilgængelig for Team- og Enterprise-kunder | | ISO 27001 | Certificeret; certifikatet er tilgængeligt for Team- og Enterprise-kunder | | HIPAA | Understøttet med en underskrevet Business Associate Agreement og HIPAA-tilkøbet, Team-planen og opefter | | Kryptering | AES-256 i hvile, TLS under transport; adgangstokens og nøgler er desuden krypteret på applikationsniveau | | Backups | Daglige for betalte projekter; Point in Time Recovery som tilkøb fra Pro-planen | | Dataplacering | Database, Auth og Storage forbliver i den AWS-region, du vælger | Intet af det beskytter en tabel, du har lagt åben. [SOC 2-guiden](https://supabase.com/docs/guides/security/soc-2-compliance) siger det ligeud: Supabases compliance overføres ikke til noget uden for dets kontrol. ## Hvad er din del? Supabases [model for delt ansvar](https://supabase.com/docs/guides/deployment/shared-responsibility-model) angiver, hvad der altid er dit: din konto, adgangsstyring til databasen og dens tabeller, dine data og at anvende sikkerhedskontroller, herunder de advarsler, Security Advisor rejser. I praksis er det fire lag af indstillinger: ![Hvem vogter hvert trin i en anmodning. Supabase driver transporten og nøglerne; rettigheder og policies er dine. Fra en browser: Browser → TLS, nøgle · Supabase → Rettighed · dig → RLS · dig; Fra din server: Server → TLS · Supabase → Secret key · dig → RLS omgås.](https://madsalt.tech/charts/da/is-supabase-secure.svg) *Figur 1. Baseret på Supabases model for delt ansvar og guiden til API-nøgler, oktober 2026.* 1. **Hvem der kan røre en tabel.** Rettigheder afgør, om `anon` og `authenticated` overhovedet når en tabel. RLS-policies afgør, hvilke rækker. 2. **Hvilken nøgle der hører hvor.** Publishable key er offentlig med vilje, secret key omgår RLS. Jeg sammenlignede dem i [Supabase anon key vs service role key](https://madsalt.tech/da/blog/supabase-anon-key-vs-service-role-key/). 3. **Auth-indstillinger.** E-mailbekræftelse, leaked password protection (Pro-planen og opefter), minimumslængde for adgangskoder, MFA, redirect-URL'er, CAPTCHA. 4. **Alt omkring databasen.** Storage-buckets og deres policies, `SECURITY DEFINER`-funktioner, Edge Functions der bruger secret key, og hvilke schemas Data API'et eksponerer. ## Hvor meget ændrer én indstilling? Jeg kørte den samme anmodning mod én tabel med tre falske ordrer på en lokal Supabase (CLI 2.109.1, Postgres 17.6, PostgREST 14.14), med publishable key, som en browser ville gøre: | Indstilling på tabellen | Hvad den offentlige nøgle fik | | ------------------------------------ | -------------------------------------------------- | | RLS slået fra | Alle 3 rækker, og en indsættelse gav `201 Created` | | RLS slået til, ingen policy | `[]` | | RLS slået til, policy `using (true)` | Alle 3 rækker | | Ingen rettighed til `anon` | `42501 permission denied` | Samme platform, samme kryptering, samme certificeringer. Forskellen er en linje SQL. Derfor er en "sikker platform" og en app, der lækker, ikke en modsigelse: [CVE-2025-48757](https://mattpalmer.io/posts/2025/05/statement-on-CVE-2025-48757/) fandt 170 af 1.645 Lovable-showcase-apps, der udleverede data til den offentlige nøgle, alle på den samme auditerede platform. ## Bliver Supabase sikrere som standard? Ja, i trin. Supabases [changelog fra 28. april 2026](https://supabase.com/changelog/45329-breaking-change-tables-not-exposed-to-data-and-graphql-api-automatically) nævner en kontakt til RLS slået til som standard, et mærke for eksponering i Data API'et, detaljerede rettigheder pr. tabel og en begrænsning af opslag af schemas. Det største trin kommer 30. oktober 2026: nye tabeller i eksisterende projekter holder op med automatisk at få Data API-rettigheder, så en glemt tabel svarer `42501` i stedet for sine rækker. Eksisterende tabeller beholder deres rettigheder, så det retter intet, der allerede er åbent. De gamle nøgler `anon` og `service_role` udfases også inden udgangen af 2026 til fordel for publishable og secret keys; den nye secret key afviser anmodninger fra en browser. Hvad skiftet ellers ødelægger, og hvordan du tjekker dit projekt før: [Supabase 30. oktober: hvad knækker, og hvordan tjekker du](https://madsalt.tech/da/blog/supabase-october-30-grant-change/). ## Hvordan tjekker du dit eget projekt? Start med Supabases eget Security Advisor, og ret hver advarsel. Tjek derefter det, den ikke dækker: - Kør det gratis [Supabase sikkerhedstjek](https://madsalt.tech/da/tools/supabase-security-check/). Det forbinder skrivebeskyttet og bedømmer projektet efter 46 regler koblet til OWASP Top 10:2025: RLS, policies, views, funktioner, rettigheder, storage og auth-indstillinger, med rette-SQL til hvert fund. - Test med to brugere i to virksomheder. Ingen scanner ved, hvilke rækker der tilhører hvem; testen står i min [sikkerhedstjekliste til Lovable-apps](https://madsalt.tech/da/blog/lovable-app-security-checklist/). - Hvis din app har roller og en tilladelsesskærm, så bevis, at hvert tilladelsesfelt gør det, det siger, som i [sådan tester du Supabase RLS](https://madsalt.tech/da/blog/how-to-test-supabase-rls/). Så: Supabase er et sikkert sted at opbevare data, og det giver dig værktøjerne til at holde dem private. Om de forbliver private, afgøres i dit schema og dine indstillinger. Overvejer du Supabase til et projekt? Jeg udveksler gerne erfaringer om, hvad du bør sætte op først. Ingen salgstale. [Kontakt mig](https://madsalt.tech/da/#contact)