Supabase "RLS disabled in public": vad det betyder

Jag har byggt en gratis Supabase-säkerhetskontroll, och dess första regel, “RLS avstängt på exponerade tabeller”, är samma fynd som Supabases Security Advisor rapporterar som ett fel. Det är det vanligaste hålet jag hittar i appar byggda med AI-verktyg, så här är vad det betyder och vad det tillät när jag återskapade det.

Vad betyder “RLS disabled in public”?

Security Advisor kör en lint som heter rls_disabled_in_public. Dess SQL flaggar en tabell när tre saker är sanna samtidigt:

1. Det är en vanlig tabell med row level security avstängt.
2. anon eller authenticated har SELECT på den.
3. Dess schema står i Data API:ets lista Exposed schemas, som är public som standard.

Lint-sidan rankar den som ERROR och kallar full create, read, update och delete över internet “a critically unsafe configuration”. “public” i namnet är schemat, men linten täcker varje exponerat schema, vilket är varför ett extra schema på den listan också förtjänar en titt; det skrev jag om i Supabase exposed schemas.

Vad kan den publika nyckeln göra med en sådan tabell?

Jag skapade en tabell orders med tre falska kunder på en lokal Supabase-stack (CLI 2.109.1, Postgres 17.6, PostgREST 14.14), med de behörigheter befintliga projekt ger nya tabeller, och RLS avstängt. Sedan anropade jag Data API:et med publishable key, som en webbläsare gör:

Förfrågan med publishable key	RLS av	RLS på, ingen policy
GET /rest/v1/orders?select=*	200, alla 3 rader med namn och e-postadresser	200, []
POST /rest/v1/orders med en ny rad	201 Created	401, 42501 “new row violates row-level security policy”

Alla som öppnar din app kan kopiera publishable key från sidan. Med RLS avstängt är nyckeln ett läs- och skrivpass till den tabellen.

Hur fixar du det utan att förstöra appen?

Att bara aktivera RLS gör att tabellen inte returnerar något till appen, eftersom det inte finns någon policy än. Den tomma skärmen är när folk, och AI-verktyg, lägger till en policy med using (true), som ger tillbaka varje rad till alla. Varför uppdateringar och borttagningar då rapporterar lyckat utan att ändra något finns i Så aktiverar du RLS i Supabase och vad du får tillbaka. Skriv de riktiga policyerna i samma 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);

Om en tabell är tänkt att vara publik, som en lista över publicerade artiklar, behåll RLS på ändå och skriv en select-policy för anon, utan skrivbehörigheter. Om du aldrig använder Data API:et och pratar med Postgres bara från din server, ta bort public från Exposed schemas i stället, som Supabases underhållare föreslog i samma issue.

För att se till att nya tabeller aldrig börjar utan RLS har Supabases guide om event triggers en trigger som aktiverar det på varje tabell som skapas i public. Och från den 30 oktober 2026 får nya tabeller inga Data API-behörigheter som standard, så de svarar 42501 tills du ger dem behörighet; det tog jag upp i Supabase 42501 permission denied.

Vad bevisar inte ett rent resultat?

Att RLS är på säger inget om huruvida policyerna är rätt. I samma test gav en policy skriven som using (true) den publika nyckeln alla 3 rader igen, och den här linten tiger när RLS väl är på. Kontrollen har en separat regel för det, “Policyer som släpper in varje rad”, och hur du testar Supabase RLS visar hur du bevisar varje policy mot riktiga användare. Policyer att utgå från, var och en körd mot riktiga användare genom API:t, finns i Supabase RLS policy-exempel, testade via API:t.