Supabase exposed schemas: vad listan öppnar för

Jag har byggt en gratis Supabase-säkerhetskontroll, och listan Exposed schemas är en av de första sakerna den läser. När någon frågar hur säkert ett Supabase-projekt är, börjar jag här.

Vad betyder “exposed schemas” i Supabase Data API?

Supabase serverar din databas över REST med PostgREST. PostgREST svarar bara för schemana i sin db_schema-lista, som du redigerar i Dashboard under Project Settings → Data API → Exposed schemas. I projektkonfigurationen jag tittade på var värdet public,graphql_public, och Supabases guide om custom schemas säger att public är exponerat som standard. En förfrågan om ett schema utanför listan avvisas, och PostgREST tillåter aldrig pg_catalog eller information_schema i den.

Varför spelar listan roll?

Allt i ett exponerat schema kan nås med den publika nyckeln: tabeller, vyer och funktioner. Supabases RLS-guide är tydlig: en tabell i ett exponerat schema utan RLS kan läsas och skrivas av varje roll som har en behörighet på den. Ett schema som inte står på listan går inte alls att nå via API:et.

Så ett extra schema är ingen neutral ändring. Lägg till storage eller vault i listan och du har lagt interna tabeller inom räckhåll för Data API:et. Lägg till ditt eget schema och varje tabell i det kräver samma omsorg som public.

Hur bedömer kontrollen extra scheman?

Kontrollen heter extra_exposed_schemas. Allt utom public och graphql_public räknas som extra, och sedan gäller:

• Ett internt Supabase-schema på listan (auth, storage, realtime, vault, extensions och liknande) är ett fel med hög allvarlighet.
• Bara egna scheman, till exempel api, ger en varning med medelhög allvarlighet.
• Inga extra scheman ger godkänt.

Samma lista styr andra kontroller. Tabeller med RLS avstängt, skrivbehörigheter för anon, policyer som alltid är sanna, vyer utan security_invoker och SECURITY DEFINER-funktioner som anon kan anropa rapporteras bara för exponerade scheman, eftersom det är där den publika nyckeln når dem.

Hur använder du ett eget schema säkert?

Ett eget schema är ett legitimt mönster: Supabases guide Securing your API beskriver ett dedikerat schema som api som ett sätt att göra den exponerade ytan lättare att identifiera och granska, medan interna tabeller ligger kvar i scheman som inte är exponerade. Två steg får det att fungera, och guiden om custom schemas beskriver båda: lägg till schemat i Exposed schemas och ge sedan usage på det till anon, authenticated och service_role, plus behörigheter på dess objekt.

Guidens exempel ger ALL på varje tabell. Den raden skulle jag inte kopiera som den står. Guiden Securing your API säger att varje roll bara ska få det minsta den behöver, och att du ska aktivera RLS på varje tabell du exponerar. Behörigheter avgör om en roll över huvud taget kan röra en tabell, policyer avgör vilka rader.

En separat ändring: Supabase slutar automatiskt ge Data API:et åtkomst till nya public-tabeller. Det blev standard för nya projekt från 30 maj 2026 och införs för befintliga projekt den 30 oktober 2026, och befintliga tabeller behåller sina behörigheter. Det är behörighetslagret. Det ändrar inte vilka scheman som står på listan.

Hur kontrollerar du hur säkert ditt eget Supabase-projekt är?

Öppna Project Settings → Data API och läs Exposed schemas. Om där står mer än public och graphql_public, fråga vad varje extra schema används till.

Lista sedan tabellerna i dessa scheman som har RLS avstängt, och om anon redan kan läsa dem:

select n.nspname as schema,
       c.relname as "table",
       has_table_privilege('anon', c.oid, 'select') as anon_can_select
from pg_class c
join pg_namespace n on n.oid = c.relnamespace
where n.nspname in ('public', 'api')  -- your Exposed schemas
  and c.relkind in ('r', 'p')
  and not c.relrowsecurity
order by 1, 2;

Jag körde den på en tillfällig Postgres 17 med ett api-schema med en tabell med RLS och en utan, plus en public-tabell utan RLS. Den returnerade bara de två utan:

 schema | table  | anon_can_select
--------+--------+-----------------
 api    | orders | t
 public | logs   | t

Varje rad där anon_can_select är sann är en tabell som alla med din publika nyckel kan läsa, tills du aktiverar RLS eller drar tillbaka behörigheten. Frågan täcker bara tabeller. Vyer och funktioner måste granskas för sig, och det går min säkerhetschecklista för Lovable-appar igenom, medan hur jag testar Supabase RLS visar hur du bevisar att policyerna fungerar.