---
title: "Supabase \"RLS disabled in public\": hvad det betyder"
description: "Hvad Advisor-fejlen rls_disabled_in_public i Supabase betyder, hvad den offentlige nøgle gjorde ved en sådan tabel i min lokale test, og hvordan du retter den."
url: "https://madsalt.tech/da/notes/supabase-rls-disabled-in-public/"
author: "Denys Zaichenko"
author_url: "https://madsalt.tech/da/about/"
language: "da"
published: 2026-10-28
---

# Supabase "RLS disabled in public": hvad det betyder

TL;DR

"RLS Disabled in Public" (lint `0013_rls_disabled_in_public`, niveau ERROR) betyder, at en tabel i et eksponeret schema har row level security slået fra, mens `anon` eller `authenticated` kan læse fra den med select. I min lokale test læste den offentlige nøgle 3 af 3 rækker fra sådan en tabel og indsatte en ny med `201 Created`. Slå RLS til, tilføj en policy pr. operation, og tjek rettighederne, alt i én migrering.

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

![Én tabel, den offentlige nøgle, RLS slået fra og til. Lokal Supabase, 3 rækker falske ordrer. RLS slået fra, læsning: Publishable key → orders, RLS slået fra → 3 af 3 rækker; RLS slået fra, indsættelse: Publishable key → orders, RLS slået fra → 201 Created; RLS slået til, endnu ingen policy: Publishable key → orders, RLS slået til → 0 rækker.](https://madsalt.tech/charts/da/supabase-rls-disabled-in-public.svg)

*Min genskabelse på en lokal Supabase, 23. oktober 2026.*

| 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](https://madsalt.tech/da/blog/how-to-enable-rls-in-supabase/). Skriv de rigtige policies i den samme 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);
```

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

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