Supabase "RLS disabled in public": hva det betyr

Jeg har bygget en gratis Supabase-sikkerhetssjekk, og den første regelen, “RLS slått av på eksponerte tabeller”, er det samme funnet som Supabases Security Advisor rapporterer som en feil. Det er det vanligste hullet jeg finner i apper bygget med AI-verktøy, så her er hva det betyr og hva det tillot da jeg reproduserte det.

Hva betyr “RLS disabled in public”?

Security Advisor kjører en lint som heter rls_disabled_in_public. Lintens SQL flagger en tabell når tre ting er sanne samtidig:

1. Det er en vanlig tabell med row level security av.
2. anon eller authenticated har SELECT på den.
3. Skjemaet står i Data API-ets liste Exposed schemas, som er public som standard.

Lint-siden vurderer den til ERROR og kaller full create, read, update og delete over internett “a critically unsafe configuration”. “public” i navnet er skjemaet, men lintet dekker hvert eksponerte skjema, og derfor fortjener et ekstra skjema på listen også en titt; det skrev jeg om i Supabase exposed schemas.

Hva kan den offentlige nøkkelen gjøre med en slik tabell?

Jeg opprettet en tabell orders med tre falske kunder på en lokal Supabase-stack (CLI 2.109.1, Postgres 17.6, PostgREST 14.14), med tilgangene eksisterende prosjekter gir nye tabeller, og RLS av. Så kalte jeg Data API-et med publishable key, slik en nettleser gjør:

Forespørsel med publishable key	RLS av	RLS på, ingen policy
GET /rest/v1/orders?select=*	200, alle 3 rader med navn og e-poster	200, []
POST /rest/v1/orders med en ny rad	201 Created	401, 42501 “new row violates row-level security policy”

Alle som åpner appen din, kan kopiere publishable key fra siden. Med RLS av er nøkkelen en lese- og skrivepassering til den tabellen.

Hvordan fikser du det uten å ødelegge appen?

Å aktivere RLS alene gjør at tabellen ikke returnerer noe til appen, fordi det ikke finnes noen policy ennå. Den tomme skjermen er når folk, og AI-verktøy, legger til en policy med using (true), som gir alle rader tilbake til alle. Hvorfor oppdateringer og slettinger da melder suksess uten å endre noe, står i Slik aktiverer du RLS i Supabase og hva du får tilbake. Skriv de ekte policyene i samme migrasjon:

alter table public.orders enable row level security;

revoke all on table public.orders from anon, authenticated;
grant select, insert on table public.orders to authenticated;

create policy "Customers read their orders"
on public.orders for select
to authenticated
using ((select auth.uid()) = user_id);

create policy "Customers create their orders"
on public.orders for insert
to authenticated
with check ((select auth.uid()) = user_id);

Hvis en tabell skal være offentlig, som en liste over publiserte artikler, behold RLS på likevel og skriv én select-policy for anon, uten skrivetilganger. Hvis du aldri bruker Data API-et og snakker med Postgres bare fra serveren din, fjern public fra Exposed schemas i stedet, slik Supabases vedlikeholdere foreslo i samme issue.

For å sikre at nye tabeller aldri starter uten RLS har Supabases guide om event triggers en trigger som aktiverer det på hver tabell som opprettes i public. Og fra 30. oktober 2026 får nye tabeller ingen Data API-tilganger som standard, så de svarer 42501 til du gir dem tilgang; det tok jeg for meg i Supabase 42501 permission denied.

Hva beviser ikke et rent resultat?

At RLS er på, sier ingenting om policyene er riktige. I den samme testen ga en policy skrevet som using (true) den offentlige nøkkelen alle 3 rader igjen, og dette lintet tier når RLS først er på. Sjekken har en egen regel for det, “Policyer som slipper inn alle rader”, og hvordan du tester Supabase RLS viser hvordan du beviser hver policy mot ekte brukere. Policyer å ta utgangspunkt i, hver kjørt mot ekte brukere gjennom API-et, står i Supabase RLS policy-eksempler, testet via API-et.