Ist Supabase sicher? Anon-Key, RLS und was offenliegt (2026)

RLS aktivieren

Supabase exponiert deine PostgreSQL-Datenbank per Anon-Key direkt gegenüber Clients. Ohne RLS-Policies kann jeder mit deiner Projekt-URL alle Daten in ungeschützten Tabellen lesen, ändern oder löschen. Das ist das Datenmodell: In Supabase ist die Datenbank die Autorisierungs-Schicht. Bleibt RLS deaktiviert, gibt es keine zweite Verteidigungslinie.

Der Anon-Key darf genau das, was deine Policies erlauben. Ohne Policies darf er alles.

Häufige Sicherheitsprobleme

Fehlende RLS-Policies

Tabellen ohne aktiviertes RLS sind für jeden mit dem Anon-Key vollständig zugänglich. Jeder, der dein Frontend lädt, sieht die Supabase-URL und den Anon-Key im Network-Tab der DevTools. Damit kann er https://<project>.supabase.co/rest/v1/<table>?select=* direkt mit curl aufrufen.

Aktiviere RLS pro Tabelle und schreibe mindestens eine Policy:

alter table profiles enable row level security;

create policy "users read own profile"
  on profiles for select
  using ( auth.uid() = user_id );

create policy "users update own profile"
  on profiles for update
  using ( auth.uid() = user_id )
  with check ( auth.uid() = user_id );

Ohne with check auf update/insert kann ein Nutzer eine Zeile so ändern, dass sie nach dem Update einer anderen user_id gehört.

Leaken des Service-Role-Keys

Der service_role-Key ignoriert RLS. Im Client-Code gibt er Angreifern Vollzugriff auf die DB. Typische Leak-Pfade: ein Next.js-NEXT_PUBLIC_*-Env-Var (alles mit diesem Prefix landet im Bundle), ein echter Wert in .env.example in einem öffentlichen GitHub-Repo oder eine Vercel-Preview-Env-Var mit falschem Scope.

Der Service-Role-Key gehört ausschließlich in Server-Code (Edge Functions, API-Routes ohne NEXT_PUBLIC_-Prefix, Backend-Worker). Brauchst du ihn im Browser, fehlt eine bessere RLS-Policy.

Fehlerhafte RLS-Policies

Logikfehler in Policies öffnen unbeabsichtigte Zugriffspfade. Klassische Fallen: eine Policy nur auf select definieren und vergessen, dass update und delete ebenfalls eine brauchen; in einer using-Klausel ein Subquery auf eine andere Tabelle ohne RLS verwenden; oder true als Platzhalter setzen und nie zurückkommen, um den echten Check einzubauen.

Schreibe pgTAP-Tests pro Policy und lass sie im CI laufen.

Storage-Bucket-Fehlkonfiguration

Supabase-Storage benötigt ebenfalls RLS, und öffentliche Buckets können sensible Dateien exponieren. Setze bei Uploads zusätzlich eine MIME-Allowlist und ein Größenlimit.

create policy "users read own files"
  on storage.objects for select
  using ( bucket_id = 'avatars' and auth.uid()::text = (storage.foldername(name))[1] );

Edge-Functions ohne Auth-Check

Edge Functions auf Supabase laufen mit dem Service-Role-Key, wenn du sie nicht explizit anders konfigurierst. Eine Function, die einen Request annimmt und eine DB-Operation ausführt, ohne den eingehenden JWT zu verifizieren, ist ein offener Endpoint, der RLS umgeht. Verifiziere immer req.headers.get('Authorization') und nutze den User-Token für den DB-Call statt des Service-Role-Keys.

Realtime und Postgres-Changes

Supabase-Realtime respektiert RLS für postgres_changes-Subscriptions, aber nur, wenn du es einschaltest. Eine Subscription auf eine Tabelle ohne RLS streamt jede Änderung an jeden verbundenen Client.

Sicherheitsbewertung

Stärken

• • PostgreSQL mit Enterprise-Grade-Sicherheit
• • Row-Level-Security (RLS) für feingranulare Zugriffskontrolle
• • Eingebaute Authentifizierung mit JWT-Tokens
• • Open Source, Security-auditierbar
• • SOC-2-Type-II-Compliance

Bedenken

• • RLS-Policies oft fehlend oder falsch konfiguriert
• • Standardkonfigurationen können Daten offenlegen
• • Anon-Key geht in den Client, RLS ist daher Pflicht
• • Leak des Service-Role-Keys gibt Vollzugriff
• • Komplexe RLS-Syntax führt zu Security-Lücken

Enterprise-Aspekte

Supabase bietet auf den Pro- und Team-Plänen SSO (SAML), Audit-Logs für Dashboard-Aktionen und Branch-Datenbanken für isolierte Preview-Umgebungen. Wenn du in einem regulierten Umfeld arbeitest, sind drei Punkte besonders relevant:

• SOC-2-Boundary: Supabase ist SOC-2-Type-II-konform, aber die Compliance gilt für die Plattform, nicht für deine Policies. Eine fehlende RLS-Policy ist im Audit dein Finding.
• Audit-Logs: Aktiviere Audit-Logs und leite sie nach S3 oder Datadog. Ohne Off-Site-Logs fehlt im Incident-Fall der Nachweis, wer den Service-Role-Key gedreht oder eine Policy entfernt hat.
• Branch-DBs für PRs: Nutze Branching, statt produktive Daten in Preview-Umgebungen zu kopieren. Eine geleakte Preview-URL mit echten Nutzerdaten ist ein DSGVO-Vorfall.

Das Fazit

Supabase ist als Plattform sicher. Entscheidend ist deine RLS-Konfiguration: RLS auf jeder Tabelle, getestete Policies, kein service_role-Key im Client-Code.

Drei Prüfungen vor jedem Launch:

1. select * from pg_tables where rowsecurity = false and schemaname = 'public' liefert eine leere Liste.
2. Das Frontend-Bundle enthält weder service_role noch andere Keys außer dem Anon-Key.
3. Ein zweiter Test-Nutzer kann keine Daten des ersten lesen. Kommt etwas durch, ist die Policy falsch.

Verwandte Ressourcen

Supabase absichern

Schritt-für-Schritt-Security-Guide mit RLS-Patterns, JWT-Validierung und Storage-Hardening.

Supabase-Security-Checkliste

Interaktive Security-Checkliste, von „RLS auf jeder Tabelle" bis „Audit-Logs aktiviert".

Supabase RLS Checker

Automatisierter Scan, der jede Tabelle deines Projekts auf aktiviertes RLS und mindestens eine Policy prüft.

Token Leak Checker

Findet geleakte Service-Role-Keys, Anon-Keys und JWT-Secrets in deinem Frontend-Bundle und in deinen Repos.

Vibe-Coding-Sicherheitsrisiken

Übersicht der Fehlermuster, die KI-generierter Code in Supabase-Projekten typischerweise einführt.

Scanne deine Supabase-App

VibeEval prüft deine Supabase-Anwendung auf Tabellen ohne Policies, geleakte Keys, öffentliche Storage-Buckets und BOLA in Edge Functions. Die Ergebnisse enthalten Datei- und Zeilenangaben zum Fixen.