---
title: "Supabase \"RLS disabled in public\": was es bedeutet"
description: "Was der Supabase-Advisor-Fehler rls_disabled_in_public bedeutet, was der öffentliche Key in meinem lokalen Test damit tat und wie Sie ihn sicher beheben."
url: "https://madsalt.tech/de/notes/supabase-rls-disabled-in-public/"
author: "Denys Zaichenko"
author_url: "https://madsalt.tech/de/about/"
language: "de"
published: 2026-10-28
---

# Supabase "RLS disabled in public": was es bedeutet

Kurz gesagt

"RLS Disabled in Public" (Lint `0013_rls_disabled_in_public`, Stufe ERROR) heißt: Eine Tabelle in einem exponierten Schema hat Row Level Security aus, während `anon` oder `authenticated` sie per select lesen kann. In meinem lokalen Test las der öffentliche Key aus so einer Tabelle alle 3 von 3 Zeilen und fügte mit `201 Created` eine neue ein. Aktivieren Sie RLS, schreiben Sie eine Policy je Operation und prüfen Sie die Grants, alles in einer Migration.

Ich habe einen kostenlosen [Supabase-Sicherheitscheck](https://madsalt.tech/de/tools/supabase-security-check/) gebaut, und seine erste Regel, "RLS bei exponierten Tabellen deaktiviert", ist derselbe Befund, den Supabases Security Advisor als Fehler meldet. Es ist die häufigste Lücke, die ich in Apps finde, die mit KI-Tools gebaut wurden, deshalb hier, was sie bedeutet und was sie erlaubte, als ich sie nachgestellt habe.

## Was bedeutet "RLS disabled in public"?

Der Security Advisor führt einen Lint namens `rls_disabled_in_public` aus. Sein [SQL](https://github.com/supabase/splinter/issues/82) meldet eine Tabelle, wenn drei Dinge gleichzeitig zutreffen:

1. Es ist eine gewöhnliche Tabelle mit ausgeschalteter Row Level Security.
2. `anon` oder `authenticated` hat `SELECT` darauf.
3. Ihr Schema steht in der Liste Exposed schemas der Data API, standardmäßig `public`.

Die [Lint-Seite](https://supabase.github.io/splinter/0013_rls_disabled_in_public/) stuft ihn als ERROR ein und nennt vollen Zugriff zum Anlegen, Lesen, Ändern und Löschen über das Internet "a critically unsafe configuration". Das "public" im Namen ist das Schema, aber der Lint deckt jedes exponierte Schema ab, weshalb auch ein zusätzliches Schema auf dieser Liste einen Blick verdient; darüber habe ich in [Supabase Exposed Schemas](https://madsalt.tech/de/notes/supabase-exposed-schemas/) geschrieben.

## Was kann der öffentliche Key mit so einer Tabelle tun?

Ich habe auf einem lokalen Supabase-Stack (CLI 2.109.1, Postgres 17.6, PostgREST 14.14) eine Tabelle `orders` mit drei erfundenen Kunden angelegt, mit den Grants, die bestehende Projekte neuen Tabellen geben, und RLS aus. Dann habe ich die Data API mit dem publishable key aufgerufen, wie es ein Browser tut:

![Eine Tabelle, der öffentliche Key, RLS aus und an. Lokales Supabase, 3 Zeilen erfundener Bestellungen. RLS aus, Lesen: Publishable key → orders, RLS aus → 3 von 3 Zeilen; RLS aus, Insert: Publishable key → orders, RLS aus → 201 Created; RLS an, noch keine Policy: Publishable key → orders, RLS an → 0 Zeilen.](https://madsalt.tech/charts/de/supabase-rls-disabled-in-public.svg)

*Meine Nachstellung auf einem lokalen Supabase-Stack, 23. Oktober 2026.*

| Anfrage mit dem publishable key              | RLS aus                                            | RLS an, keine Policy                                      |
| -------------------------------------------- | -------------------------------------------------- | --------------------------------------------------------- |
| `GET /rest/v1/orders?select=*`               | `200`, alle 3 Zeilen mit Namen und E-Mail-Adressen | `200`, `[]`                                               |
| `POST /rest/v1/orders` mit einer neuen Zeile | `201 Created`                                      | `401`, 42501 "new row violates row-level security policy" |

Jeder, der Ihre App öffnet, kann den publishable key aus der Seite kopieren. Bei ausgeschalteter RLS ist der Key ein Lese- und Schreibzugang zu dieser Tabelle.

## Wie beheben Sie das, ohne die App kaputt zu machen?

RLS allein zu aktivieren lässt die Tabelle für die App nichts mehr liefern, weil noch keine Policy existiert. Dieser leere Bildschirm ist der Moment, in dem Menschen, und KI-Tools, eine Policy mit `using (true)` hinzufügen, die jedem jede Zeile zurückgibt. Warum Updates und Deletes dann Erfolg melden, obwohl nichts geändert wird, steht in [Supabase RLS aktivieren: was jede Anfrage danach liefert](https://madsalt.tech/de/blog/how-to-enable-rls-in-supabase/). Schreiben Sie die echten Policies in derselben Migration:

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

Soll eine Tabelle öffentlich sein, etwa eine Liste veröffentlichter Artikel, lassen Sie RLS trotzdem an und schreiben Sie eine `select`-Policy für `anon`, ohne Schreib-Grants. Nutzen Sie die Data API nie und sprechen nur von Ihrem Server mit Postgres, entfernen Sie stattdessen `public` aus Exposed schemas, wie es Supabases Maintainer im [selben Issue](https://github.com/supabase/splinter/issues/82) vorschlugen.

Damit neue Tabellen nie ohne RLS starten, hat Supabases [Leitfaden zu Event Triggern](https://supabase.com/docs/guides/database/postgres/event-triggers) einen Trigger, der RLS für jede in `public` angelegte Tabelle aktiviert. Und ab dem 30. Oktober 2026 bekommen neue Tabellen standardmäßig keine Data-API-Grants, antworten also mit `42501`, bis Sie sie vergeben; das habe ich in [Supabase 42501 permission denied](https://madsalt.tech/de/notes/supabase-42501-permission-denied/) behandelt.

## Was beweist ein sauberes Ergebnis nicht?

Dass RLS an ist, sagt nichts darüber, ob die Policies stimmen. Im selben Test gab eine als `using (true)` geschriebene Policy dem öffentlichen Key wieder alle 3 Zeilen, und dieser Lint schweigt, sobald RLS an ist. Der Check hat dafür eine eigene Regel, "Policies, die jede Zeile erlauben", und [Supabase RLS testen](https://madsalt.tech/de/blog/how-to-test-supabase-rls/) zeigt, wie Sie jede Policy an echten Nutzern beweisen. Policies als Ausgangspunkt, je an echten Nutzern über die API ausgeführt, stehen in [Supabase RLS Policy Beispiele, je per API getestet](https://madsalt.tech/de/blog/supabase-rls-policy-examples/).