Är Supabase säkert? Vad det täcker och vad du måste

Jag heter Denys och är full-stack- och AI-ingenjör, och de flesta appar jag bygger eller rättar körs på Supabase. Kunder frågar “är Supabase säkert?” när de menar “är min data säker?”. Det är två olika svar, så den här artikeln tar dem ett i taget.

Är Supabase-plattformen säker?

Plattformssidan granskas av tredje part. Från Supabases säkerhetssida och säkerhetsdokumentation, läst den 23 oktober 2026:

Kontroll	Vad Supabase uppger
SOC 2 Type 2	Granskas varje år; rapporten finns för Team- och Enterprise-kunder
ISO 27001	Certifierat; certifikatet finns för Team- och Enterprise-kunder
HIPAA	Stöds med ett undertecknat Business Associate Agreement och HIPAA-tillägget, Team-planen och uppåt
Kryptering	AES-256 i vila, TLS under överföring; åtkomsttokens och nycklar krypteras också på applikationsnivå
Säkerhetskopior	Dagliga för betalda projekt; Point in Time Recovery som tillägg från Pro-planen
Dataplacering	Databas, Auth och Storage stannar i den AWS-region du väljer

Inget av detta skyddar en tabell du lämnat öppen. SOC 2-guiden säger det rakt ut: Supabases efterlevnad överförs inte till något utanför Supabases kontroll.

Vad är din del?

Supabases modell för delat ansvar listar vad som alltid är ditt: ditt konto, åtkomsthantering för databasen och dess tabeller, din data och att tillämpa säkerhetskontroller, inklusive varningarna Security Advisor ger. I praktiken betyder det fyra lager av inställningar:

1. Vem som kan röra en tabell. Behörigheter (grants) avgör om anon och authenticated över huvud taget når en tabell. RLS-policyer avgör vilka rader.
2. Vilken nyckel som hör var. Publishable key är publik by design, secret key kringgår RLS. Jag jämförde dem i Supabase anon key vs service role key.
3. Auth-inställningar. E-postbekräftelse, leaked password protection (Pro-planen och uppåt), minsta lösenordslängd, MFA, redirect-URL:er, CAPTCHA.
4. Allt runt databasen. Storage-buckets och deras policyer, SECURITY DEFINER-funktioner, Edge Functions som använder secret key och vilka scheman Data API:et exponerar.

Hur mycket ändrar en inställning?

Jag körde samma förfrågan mot en tabell med tre falska beställningar på en lokal Supabase-stack (CLI 2.109.1, Postgres 17.6, PostgREST 14.14), med publishable key, som en webbläsare skulle göra:

Inställning på tabellen	Vad den publika nyckeln fick
RLS av	Alla 3 rader, och en insert gav 201 Created
RLS på, ingen policy	[]
RLS på, policy using (true)	Alla 3 rader
Ingen behörighet för anon	42501 permission denied

Samma plattform, samma kryptering, samma certifieringar. Skillnaden är en rad SQL. Därför är en “säker plattform” och en läckande app ingen motsägelse: CVE-2025-48757 fann 170 av 1 645 Lovable-showcase-appar som levererade data till den publika nyckeln, alla på samma granskade plattform.

Blir Supabase säkrare som standard?

Ja, i steg. Supabases changelog från 28 april 2026 listar en växel för RLS på som standard, en markering för Data API-exponering, detaljerade behörigheter per tabell och en begränsning av schemauppslag. Den största kommer den 30 oktober 2026: nya tabeller i befintliga projekt får inte längre Data API-behörigheter automatiskt, så en bortglömd tabell returnerar 42501 i stället för sina rader. Befintliga tabeller behåller sina behörigheter, så det här fixar inget som redan står öppet. De äldre nycklarna anon och service_role avvecklas också till slutet av 2026 till förmån för publishable och secret keys; den nya secret key avvisar förfrågningar från en webbläsare.

Vad mer omställningen förstör och hur du kollar projektet i förväg: Supabase 30 oktober: vad som går sönder och hur du kollar.

Hur kontrollerar du ditt eget projekt?

Börja med Supabases egen Security Advisor och åtgärda varje varning. Kontrollera sedan det den inte täcker:

• Kör den gratis Supabase-säkerhetskontrollen. Den ansluter skrivskyddat och betygsätter projektet mot 46 regler kopplade till OWASP Top 10:2025: RLS, policyer, vyer, funktioner, behörigheter, storage och auth-inställningar, med fix-SQL för varje fynd.
• Testa med två användare i två företag. Ingen skanner vet vilka rader som tillhör vem; testet finns i min säkerhetschecklista för Lovable-appar.
• Om din app har roller och en behörighetsskärm, bevisa att varje behörighetsruta gör vad den säger, som i hur du testar Supabase RLS.

Så: Supabase är en säker plats att lagra data på, och det ger dig verktygen att hålla den privat. Om den förblir privat avgörs i ditt schema och dina inställningar.