Supabase Row Level Security: 7 Fehler in KI-gebauten Apps

Wenn Ihre App mit Lovable, Bolt oder einem ähnlichen KI-Builder erstellt wurde, nutzt sie mit hoher Wahrscheinlichkeit Supabase für Datenbank und Login. Das ist eine vernünftige Wahl. Es bedeutet aber auch, dass eine einzige Einstellung darüber entscheidet, ob die Daten Ihrer Kunden privat oder öffentlich sind: Row Level Security, meist kurz RLS genannt.

Sicherheitsforscher berichteten 2025 öffentlich, dass eine große Zahl von Apps, die mit einem beliebten KI-Builder erzeugt wurden, Nutzerdaten offenlegte, weil RLS-Policies fehlten oder zu schwach waren. Die Apps funktionierten im Test einwandfrei, da der Builder und der Eigentümer immer alles sehen konnten. Das Problem zeigt sich erst, wenn ein anderer Nutzer oder ein Angreifer Daten abfragt, die ihm nicht gehören.

Dieser Leitfaden erklärt RLS in einfachen Worten und geht dann die sieben häufigsten Fehler in KI-generierten Supabase-Projekten durch – jeweils mit der passenden Lösung.

RLS in einfachen Worten

Supabase gibt Ihrem Frontend über eine automatisch generierte API direkten Zugriff auf Ihre Datenbank. Der „anon“-Schlüssel, der in Ihrer Website steckt, ist von Haus aus öffentlich. Jeder kann ihn aus dem Browser kopieren. Ihre Daten schützt nicht der Schlüssel, sondern die Regeln, die an jede Tabelle geknüpft sind.

Row Level Security ist dieses Regelwerk. Jede Regel (eine Policy) legt fest, welche Zeilen eine bestimmte Art von Nutzer lesen, einfügen, ändern oder löschen darf. Eine typische Regel lautet: „Ein angemeldeter Nutzer kann Zeilen lesen, bei denen user_id seiner eigenen ID entspricht.“ Ist RLS für eine Tabelle deaktiviert oder sind die Policies zu großzügig, greift das Regelwerk nicht, und die API antwortet jedem.

Fehler 1: RLS wurde nie aktiviert

Tabellen, die per SQL oder Migrationsdateien erstellt werden, sind erst geschützt, wenn Sie RLS für sie aktivieren. KI-Tools legen häufig Tabellen an, bauen die Screens und machen weiter. Alles funktioniert, weil es überhaupt keine Einschränkungen gibt.

Zur Prüfung führen Sie Folgendes im Supabase-SQL-Editor aus und suchen nach Tabellen im Schema public, bei denen rowsecurity false ist:

select schemaname, tablename, rowsecurity
from pg_tables
where schemaname = 'public';

Aktivieren Sie RLS mit einer Zeile pro Tabelle und fügen Sie dann Policies hinzu. Wird RLS ohne Policies aktiviert, wird alles blockiert – das ist der sichere Ausgangspunkt, auf dem Sie aufbauen:

alter table public.invoices enable row level security;

Das Supabase-Dashboard enthält außerdem einen Security Advisor, der Tabellen ohne RLS markiert. Führen Sie ihn vor jedem Launch aus.

Fehler 2: Policies, die alles erlauben

Stößt ein KI-Tool auf einen Fehler „permission denied“, ist eine häufige Abkürzung eine Policy wie using (true). Sie lässt den Fehler verschwinden und macht die Daten gleichzeitig öffentlich.

-- Looks harmless, exposes every row to every user:
create policy "Allow read" on public.invoices
for select using (true);

Ersetzen Sie sie durch eine Regel, die an den angemeldeten Nutzer gebunden ist:

create policy "Users can read their own invoices"
on public.invoices for select
to authenticated
using ( (select auth.uid()) = user_id );

Wirklich öffentliche Daten, etwa ein Produktkatalog, können eine offene Leserichtlinie verwenden. Alles Persönliche, Finanzielle oder Private nicht.

Fehler 3: Der Service-Schlüssel ist offengelegt

Supabase kennt zwei relevante Schlüssel. Der anon-Schlüssel ist für Browser gedacht und verlässt sich auf RLS. Der Service-Role-Schlüssel umgeht RLS vollständig. Taucht er in Ihrem Frontend-Code, in einer Variablen, die in die Website gebündelt wird, oder in einem öffentlichen Repository auf, ist jede von Ihnen geschriebene Policy bedeutungslos.

Durchsuchen Sie Ihr gebautes JavaScript und Ihre Git-Historie danach. Wurde er jemals offengelegt, rotieren Sie ihn sofort im Supabase-Dashboard. Service-Schlüssel gehören ausschließlich in serverseitigen Code, etwa in eine Edge Function oder ein Backend, niemals in etwas, das der Browser herunterlädt.

Fehler 4: Rollen werden dort gespeichert, wo Nutzer sie ändern können

Ein häufiges Muster ist, Admins mit einem Feld wie role: "admin" in den Metadaten des Nutzers zu markieren und dieses dann in einer Policy oder in der Oberfläche zu prüfen. In Supabase kann der Bereich user_metadata vom angemeldeten Nutzer geändert werden. Ein Nutzer kann sich das Admin-Flag also einfach selbst geben.

Halten Sie Autorisierungsdaten an Orten, die Nutzer nicht beschreiben können: in einer eigenen Rollentabelle, die selbst durch RLS geschützt ist, oder in den serverseitig kontrollierten app_metadata. Stützen Sie Ihre Policies dann darauf.

Fehler 5: Insert- und Update-Regeln ohne „with check“

Eine Policy kann steuern, welche bestehenden Zeilen Sie anfassen dürfen (using) und welche Werte Sie schreiben dürfen (with check). Fehlt der zweite Teil, kann ein Nutzer Zeilen einfügen, die einer anderen Person gehören, oder seine eigene Zeile so ändern, dass sie an ein anderes Konto übergeht.

create policy "Users can insert their own invoices"
on public.invoices for insert
to authenticated
with check ( (select auth.uid()) = user_id );

create policy "Users can update their own invoices"
on public.invoices for update
to authenticated
using ( (select auth.uid()) = user_id )
with check ( (select auth.uid()) = user_id );

Fehler 6: Views und Funktionen, die die Regeln umgehen

Eine Datenbank-View läuft standardmäßig mit den Rechten ihres Eigentümers, wodurch sie das RLS der darunterliegenden Tabellen umgehen kann. In Postgres 15 und höher können Sie eine View mit security_invoker = true dazu bringen, die Berechtigungen des Aufrufers zu respektieren. Ebenso läuft eine Funktion, die als security definer markiert und über die API erreichbar ist, mit erhöhten Rechten; sie muss daher prüfen, wer sie aufruft, und ihren eigenen search_path festlegen.

KI-generierte „Helper“-Views und -Funktionen für Dashboards sind eine häufige Quelle dieses Problems. Prüfen Sie jede einzelne und fragen Sie: Mit wessen Berechtigungen läuft das?

Fehler 7: Storage-Buckets und Lücken bei Mehrmandantenfähigkeit

Dateien haben eigene Regeln, getrennt von den Tabellenregeln. Ein öffentlicher Bucket liefert Dateien an jeden mit dem Link aus – richtig für Logos, falsch für Verträge. Organisieren Sie private Dateien beim Hochladen nach Nutzer oder Mandant und schreiben Sie passende Storage-Policies, etwa indem Sie verlangen, dass der erste Ordner im Pfad der ID des Nutzers entspricht:

create policy "Users can read their own files"
on storage.objects for select
to authenticated
using (
  bucket_id = 'documents'
  and (storage.foldername(name))[1] = (select auth.uid()::text)
);

Bei Apps mit Teams oder Organisationen sollte jede Policy über eine Mitgliedschaftstabelle auf den Mandanten eingegrenzt sein, nicht nur auf den einzelnen Nutzer. Genau hier werden von KI geschriebene Policies von Tabelle zu Tabelle am häufigsten inkonsistent.

So testen Sie Ihre eigene App in 15 Minuten

1. Anonymer Test. Rufen Sie Ihre Tabellen-Endpunkte nur mit dem öffentlichen anon-Schlüssel und ohne Login auf. Private Tabellen sollten nichts oder einen Fehler zurückgeben.
2. Test mit zwei Konten. Legen Sie zwei Nutzer mit getrennten Daten an. Versuchen Sie als Nutzer B, die Datensätze von Nutzer A zu lesen, zu ändern und zu löschen, indem Sie IDs in den Anfragen ändern.
3. Rechte-Test. Versuchen Sie als normaler Nutzer, die Admin-Funktionen direkt aufzurufen und Ihre eigene Rolle zu ändern.
4. Führen Sie den Security Advisor aus und beheben Sie jede Warnung zu RLS.
5. Behalten Sie die Tests. Supabase unterstützt automatisierte Datenbanktests, damit eine künftige Änderung nicht unbemerkt eine Lücke wieder öffnet.

Wenn Sie bereits live sind

Aktivieren Sie zuerst RLS und korrigieren Sie die Policies, rotieren Sie dann alle offengelegten Schlüssel. Prüfen Sie Ihre Logs auf ungewöhnliche Zugriffe. Wenn personenbezogene Daten echter Nutzer möglicherweise offengelegt wurden, können je nach deren Wohnort rechtliche Informationspflichten bestehen – sprechen Sie daher mit einem Anwalt. Die Zugriffsregeln zu korrigieren geht meist schnell. Herauszufinden, was passiert ist und was offengelegt werden muss, dauert länger – ein weiterer Grund, diese Probleme vor dem Launch zu finden.

Unsicher, wo Ihre App steht? Unser technisches Audit für KI-Apps prüft Ihre Policies, Schlüssel und Ihren Storage und liefert Ihnen eine priorisierte Liste von Korrekturen. Wenn Sie bereits wissen, was kaputt ist, deckt Reparatur und Produktiv-Launch von KI-Apps die Fixes und einen kontrollierten Release ab. Sie können auch mit der umfassenderen Checkliste zur Produktionsreife beginnen.