Supabase "RLS disabled in public": hvad det betyder

Jeg har bygget et gratis Supabase sikkerhedstjek, og dets første regel, “RLS slået fra på eksponerede tabeller”, er det samme fund, som Supabases Security Advisor rapporterer som en fejl. Det er det mest almindelige hul, jeg finder i apps bygget med AI-værktøjer, så her er, hvad det betyder, og hvad det tillod, da jeg genskabte det.

Hvad betyder “RLS disabled in public”?

Security Advisor kører en lint, der hedder rls_disabled_in_public. Dens SQL markerer en tabel, når tre ting gælder på én gang:

1. Det er en almindelig tabel med row level security slået fra.
2. anon eller authenticated har SELECT på den.
3. Dens schema står på Data API’ets liste Exposed schemas, som som standard er public.

Lint-siden vurderer den som ERROR og kalder fuld oprettelse, læsning, opdatering og sletning over internettet “en kritisk usikker konfiguration”. “Public” i navnet er schemaet, men linten dækker hvert eksponeret schema, hvorfor et ekstra schema på listen også er værd at se på; det skrev jeg om i Supabase exposed schemas.

Hvad kan den offentlige nøgle gøre ved sådan en tabel?

Jeg oprettede en tabel orders med tre falske kunder på en lokal Supabase (CLI 2.109.1, Postgres 17.6, PostgREST 14.14), med de rettigheder, eksisterende projekter giver nye tabeller, og med RLS slået fra. Derefter kaldte jeg Data API’et med publishable key, som en browser gør det:

Anmodning med publishable key	RLS slået fra	RLS slået til, ingen policy
GET /rest/v1/orders?select=*	200, alle 3 rækker med navne og e-mails	200, []
POST /rest/v1/orders med en ny række	201 Created	401, 42501 “new row violates row-level security policy”

Enhver, der åbner din app, kan kopiere publishable key fra siden. Med RLS slået fra er nøglen et læse- og skriveadgangskort til den tabel.

Hvordan retter du det uden at ødelægge appen?

Hvis du kun slår RLS til, returnerer tabellen intet til appen, fordi der endnu ikke er nogen policy. Den tomme skærm er der, hvor folk, og AI-værktøjer, tilføjer en policy med using (true), som giver hver række tilbage til alle. Hvorfor opdateringer og sletninger så melder succes uden at ændre noget, står i Sådan aktiverer du RLS i Supabase: hvad du får tilbage. Skriv de rigtige policies i den samme migrering:

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 tabel skal være offentlig, for eksempel en liste over udgivne artikler, så behold RLS slået til alligevel og skriv én select-policy til anon, uden skriverettigheder. Hvis du aldrig bruger Data API’et og kun taler med Postgres fra din server, så fjern i stedet public fra Exposed schemas, som Supabases vedligeholdere foreslog i det samme issue.

For at sikre, at nye tabeller aldrig starter uden RLS, har Supabases guide til event triggers en trigger, der slår det til på hver tabel, der oprettes i public. Og fra 30. oktober 2026 får nye tabeller som standard ingen Data API-rettigheder, så de svarer 42501, indtil du giver dem rettigheder; det skrev jeg om i Supabase 42501 permission denied.

Hvad beviser et rent resultat ikke?

At RLS er slået til, siger intet om, hvorvidt policies er rigtige. I den samme test gav en policy skrevet som using (true) den offentlige nøgle alle 3 rækker igen, og denne lint er tavs, så snart RLS er slået til. Tjekket har en separat regel til det, “Politikker, der tillader alle rækker”, og sådan tester du Supabase RLS viser, hvordan du beviser hver policy mod rigtige brugere. Policies at tage udgangspunkt i, hver kørt mod rigtige brugere gennem API’et, står i Supabase RLS policy-eksempler, hver testet via API.