--- title: "Supabase \"RLS disabled in public\": vad det betyder" description: "Vad Supabase Advisor-felet rls_disabled_in_public betyder, vad den publika nyckeln gjorde med en sådan tabell i mitt lokala test och hur du fixar det säkert." url: "https://madsalt.tech/sv/notes/supabase-rls-disabled-in-public/" author: "Denys Zaichenko" author_url: "https://madsalt.tech/sv/about/" language: "sv" published: 2026-10-28 --- # Supabase "RLS disabled in public": vad det betyder Kort sagt "RLS Disabled in Public" (lint `0013_rls_disabled_in_public`, nivå ERROR) betyder att en tabell i ett exponerat schema har row level security avstängt medan `anon` eller `authenticated` kan göra select på den. I mitt lokala test läste den publika nyckeln alla 3 av 3 rader från en sådan tabell och la in en ny med `201 Created`. Aktivera RLS, lägg till en policy per operation och kontrollera behörigheterna, allt i en migrering. Jag har byggt en gratis [Supabase-säkerhetskontroll](https://madsalt.tech/sv/tools/supabase-security-check/), 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](https://github.com/supabase/splinter/issues/82) 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](https://supabase.github.io/splinter/0013_rls_disabled_in_public/) 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](https://madsalt.tech/sv/notes/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: ![En tabell, den publika nyckeln, RLS av och på. Lokal Supabase, 3 rader falska beställningar. RLS av, läsning: Publishable key → orders, RLS av → 3 av 3 rader; RLS av, insättning: Publishable key → orders, RLS av → 201 Created; RLS på, ingen policy än: Publishable key → orders, RLS på → 0 rader.](https://madsalt.tech/charts/sv/supabase-rls-disabled-in-public.svg) *Min reproduktion på en lokal Supabase-stack, 23 oktober 2026.* | 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](https://madsalt.tech/sv/blog/how-to-enable-rls-in-supabase/). Skriv de riktiga policyerna i samma migrering: ```sql 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](https://github.com/supabase/splinter/issues/82). För att se till att nya tabeller aldrig börjar utan RLS har Supabases [guide om event triggers](https://supabase.com/docs/guides/database/postgres/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](https://madsalt.tech/sv/notes/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](https://madsalt.tech/sv/blog/how-to-test-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](https://madsalt.tech/sv/blog/supabase-rls-policy-examples/).