---
title: "Supabase \"RLS disabled in public\": hva det betyr"
description: "Hva Advisor-feilen rls_disabled_in_public betyr, hva den offentlige nøkkelen gjorde med en slik tabell i min lokale test, og hvordan du fikser den."
url: "https://madsalt.tech/no/notes/supabase-rls-disabled-in-public/"
author: "Denys Zaichenko"
author_url: "https://madsalt.tech/no/about/"
language: "no"
published: 2026-10-28
---

# Supabase "RLS disabled in public": hva det betyr

TL;DR

"RLS Disabled in Public" (lint `0013_rls_disabled_in_public`, nivå ERROR) betyr at en tabell i et eksponert skjema har row level security av mens `anon` eller `authenticated` kan gjøre select på den. I den lokale testen min leste den offentlige nøkkelen alle 3 av 3 rader fra en slik tabell og la inn en ny med `201 Created`. Aktiver RLS, legg til en policy per operasjon og sjekk tilgangene, alt i én migrasjon.

Jeg har bygget en gratis [Supabase-sikkerhetssjekk](https://madsalt.tech/no/tools/supabase-security-check/), 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](https://github.com/supabase/splinter/issues/82) 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](https://supabase.github.io/splinter/0013_rls_disabled_in_public/) 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](https://madsalt.tech/no/notes/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:

![Én tabell, den offentlige nøkkelen, RLS av og på. Lokal Supabase, 3 rader med falske bestillinger. RLS av, lesing: Publishable key → orders, RLS av → 3 av 3 rader; RLS av, innsetting: Publishable key → orders, RLS av → 201 Created; RLS på, ingen policy ennå: Publishable key → orders, RLS på → 0 rader.](https://madsalt.tech/charts/no/supabase-rls-disabled-in-public.svg)

*Reproduksjonen min på en lokal Supabase-stack, 23. oktober 2026.*

| 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](https://madsalt.tech/no/blog/how-to-enable-rls-in-supabase/). Skriv de ekte policyene i samme migrasjon:

```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);
```

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](https://github.com/supabase/splinter/issues/82).

For å sikre at nye tabeller aldri starter uten RLS har Supabases [guide om event triggers](https://supabase.com/docs/guides/database/postgres/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](https://madsalt.tech/no/notes/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](https://madsalt.tech/no/blog/how-to-test-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](https://madsalt.tech/no/blog/supabase-rls-policy-examples/).