Supabase gibt dir in Minuten eine Datenbank und eine API, und genau das ist die Gefahr: die API ist vom ersten Moment an exponiert. Wenn du die Sicherheit nicht konfigurierst, kann jeder mit deinem öffentlichen Schlüssel deine Tabellen lesen und beschreiben. Hier ist, was du prüfen solltest.
RLS auf JEDER Tabelle aktiviert
Row Level Security ist die Hauptbarriere von Supabase. Ohne sie kann der Anon-Schlüssel ganze Tabellen direkt aus dem Browser abfragen. Der klassische Vibe-Coder-Fehler ist, schnell eine neue Tabelle anzulegen und das Aktivieren von RLS zu vergessen.
Prüfe Tabelle für Tabelle im Dashboard: taucht eine ohne RLS auf, ist sie für die Öffentlichkeit offen. Aktivieren allein reicht auch nicht: eine Tabelle mit aktivem RLS, aber ohne Policies verweigert alles, und eine mit einer zu freizügigen Policy schützt nichts.
service_role gegenüber anon
Der anon-Schlüssel ist öffentlich und geht ins Frontend: er ist dafür gedacht, von RLS gesteuert zu werden. Der service_role-Schlüssel umgeht RLS komplett und hat vollen Zugriff. Er darf niemals im Browser oder in einer NEXT_PUBLIC_-Variable auftauchen.
Nutze ihn nur auf dem Server, in Edge Functions oder vertrauenswürdigen Backends. Wenn du einen Leak vermutest, rotiere ihn sofort über das Dashboard.
Policies, die wirklich abbilden, wer was darf
Eine Policy von true für alle lässt die Tabelle offen, selbst mit aktivem RLS. Schreibe konkrete Policies: dass ein Nutzer nur seine eigenen Zeilen liest und bearbeitet, meist durch Vergleich von auth.uid() mit der Eigentümer-Spalte. Trenne die Regeln nach Operation (select, insert, update, delete): manchmal willst du Lesen erlauben, aber kein Löschen.
Storage: auch Buckets haben Regeln
Der Dateispeicher nutzt eigene Policies. Ein öffentlicher Bucket liefert jede Datei per URL an jeden aus, der sie hat. Entscheide bewusst, welche Buckets öffentlich sind, und schütze den Rest mit nutzerbasierten Policies. Lade private Dokumente in private Buckets, nicht in einen öffentlichen mit schwer zu erratenden Namen.
Secrets und Schlüssel raus aus dem Frontend
Über die service_role hinaus prüfe, dass keine Drittanbieter-Schlüssel (Stripe, E-Mail, KI) ins Client-JavaScript eingebacken sind. Die KI legt sie manchmal dorthin, um schnell etwas zum Laufen zu bringen, und sie bleiben für immer sichtbar.
Scanaris prüft dein Supabase für dich
Scanaris enthält ein optionales Supabase-Audit, das prüft, ob deine Tabellen RLS haben, und im Frontend exponierte Schlüssel erkennt. Es ist eine reine Lese-Prüfung über das, was ohnehin öffentlich ist, und jeder Fund kommt mit einem Prompt, fertig zum Einfügen in deine KI. Lass es vor dem Start laufen und du weißt, ob du eine Tür offengelassen hast.