IST SUPABASE SICHER? SICHERHEITSANALYSE 2026 | VIBEEVAL

RLS ist nicht verhandelbar

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 kein Bug — das ist das Datenmodell. Supabase wurde so entworfen, dass die DB die Autorisierungs-Schicht ist; wenn du dieses Modell brichst, indem du RLS deaktiviert lässt, gibt es keine zweite Verteidigungslinie.

Das wichtigste mentale Modell: Der Anon-Key ist nicht „der Schlüssel, der nur lesen kann" — er ist der Schlüssel, der genau das tun darf, was deine Policies erlauben. Ohne Policies ist „alles erlaubt".

Häufige Sicherheitsprobleme

Fehlende RLS-Policies

Tabellen ohne aktiviertes RLS sind für jeden mit dem Anon-Key vollständig zugänglich, was zu kompletter Datenoffenlegung führt. Jeder, der dein Frontend lädt, sieht die Supabase-URL und den Anon-Key in den Network-Tabs der DevTools — sobald er die hat, 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. Ihn im Client-Code offenzulegen, gibt Angreifern Vollzugriff auf die DB. Die häufigsten Leak-Pfade, die wir sehen: in einem Next.js-NEXT_PUBLIC_*-Env-Var (alles mit diesem Prefix landet im Bundle), in einem öffentlichen GitHub-Repo unter .env.example mit echtem Wert, oder in einer Vercel-Preview-Env-Var, die für die falsche Umgebung scoped ist.

Trenne strikt: Der Service-Role-Key gehört ausschließlich in Server-Code (Edge Functions, API-Routes ohne NEXT_PUBLIC_-Prefix, Backend-Worker). Wenn du ihn im Browser brauchst, brauchst du ihn nicht — du brauchst eine bessere RLS-Policy.

Fehlerhafte RLS-Policies

RLS-Policies mit Logikfehlern schaffen unbeabsichtigte Zugriffspfade. Komplexe Policies erfordern gründliches Testen. 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 — RLS ohne Tests ist Hoffnung, kein Schutz.

Storage-Bucket-Fehlkonfiguration

Supabase-Storage benötigt ebenfalls RLS. Öffentliche Buckets können sensible Dateien exponieren. Bei Uploads achte zusätzlich auf MIME-Allowlist und Größenlimit; sonst wird dein Bucket schnell zum kostenlosen CDN für fremde Inhalte.

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 effektiv 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 essenziell
• • 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 die Policies, die du selbst schreibst. Eine fehlende RLS-Policy ist deine Findings im Audit, nicht Supabases.
• Audit-Logs: Aktiviere Audit-Logs und ship sie nach S3 oder Datadog. Ohne Off-Site-Logs hast du im Incident-Fall keine Evidenz, 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, mit der erprobten Security von PostgreSQL. Der kritische Faktor ist die korrekte RLS-Konfiguration. Aktiviere RLS auf jeder Tabelle, schreibe und teste Policies gründlich und exponiere den service_role-Key niemals im Client-Code. Mit korrekter Konfiguration bietet Supabase exzellente Sicherheit.

Drei Prüfungen vor jedem Launch: (1) select * from pg_tables where rowsecurity = false and schemaname = 'public' — leere Liste? Gut. (2) Grep das Frontend-Bundle nach service_role und nach allen Keys, die nicht der Anon-Key sind. (3) Versuche als zweiter Test-Nutzer, Daten des ersten zu lesen. Wenn etwas durchkommt, ist deine 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

Lass VibeEval deine Supabase-Anwendung auf RLS-Fehlkonfiguration und Schwachstellen prüfen — Tabellen ohne Policies, geleakte Keys, öffentliche Storage-Buckets, BOLA in Edge Functions. Ergebnisse in unter 60 Sekunden, mit Datei- und Zeilenangaben zum Fixen.