--- title: "Supabase exposed schemas: vad listan öppnar för" description: "Supabase exposed schemas förklarat: vad inställningen betyder, hur min kontroll bedömer extra scheman och en SQL-fråga som hittar tabeller utan RLS." url: "https://madsalt.tech/sv/notes/supabase-exposed-schemas/" author: "Denys Zaichenko" language: "sv" published: 2026-10-22 --- # Supabase exposed schemas: vad listan öppnar för Kort sagt Listan Exposed schemas i Supabase avgör vilka scheman Data API:et serverar till alla som har din publika nyckel. Standard är `public` och `graphql_public`. Varje tabell, vy och funktion i ett schema på listan måste ha egna behörigheter och egen RLS, så varje extra schema är mer yta att försvara. Håll listan kort och kontrollera den först. Jag har byggt en gratis [Supabase-säkerhetskontroll](https://madsalt.tech/sv/tools/supabase-security-check/), 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](https://supabase.com/docs/guides/api/using-custom-schemas) säger att `public` är exponerat som standard. En förfrågan om ett schema utanför listan avvisas, och [PostgREST](https://docs.postgrest.org/en/stable/references/api/schemas.html) 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](https://supabase.com/docs/guides/database/postgres/row-level-security) ä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`. ![Vad ett extra exposed schema öppnar för. En anon-förfrågan före och efter att listan trimmats. Före: ett extra schema är exposed: anon-förfrågan → Data API → extra schema → tabell utan RLS kan läsas; Efter: bara public och graphql_public: anon-förfrågan → Data API → bara standardscheman → RLS på alla tabeller.](https://madsalt.tech/charts/sv/supabase-exposed-schemas.svg) *Från Supabase-kontrollens regler och Supabases Data API-dokumentation, 22 oktober 2026.* ## 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](https://supabase.com/docs/guides/api/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](https://supabase.com/docs/guides/api/using-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](https://supabase.com/changelog/45329-breaking-change-tables-not-exposed-to-data-and-graphql-api-automatically). 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: ```sql 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: ```text 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](https://madsalt.tech/sv/blog/lovable-app-security-checklist/) igenom, medan [hur jag testar Supabase RLS](https://madsalt.tech/sv/blog/how-to-test-supabase-rls/) visar hur du bevisar att policyerna fungerar.