Ist deine Supabase-App sicher?

Supabase gibt dir eine echte Postgres-Datenbank mit einer API bereits davor, und deshalb kann eine App zwanzig Minuten nach dem Start mit Live-Daten sprechen. Was Leute später überrascht: Dieselbe API ist für jeden erreichbar, von überall, mit Zugangsdaten, die in deiner App abgedruckt sind.

Hier ist der Punkt, den Anleitung um Anleitung falsch darstellt: Das ist kein Mangel, und es zu verstecken ist nicht die Lösung. Supabase ist dafür entworfen, direkt aus einem Browser abgefragt zu werden. Der Schutz sollte immer schon woanders wohnen, und zu wissen, wo, ist der größte Teil dessen, was es über den sicheren Betrieb einer Supabase-App zu wissen gibt.

Warum deine Datenbank mit Absicht im Internet steht

Weil deine App mit ihr aus dem Browser deiner Besucherin spricht und nicht von einem Server, den du betreibst.

Stell es dir als Laden vor. Deine App ist die Ladenfront, jedem Besucher vollständig ausgehändigt. Deine Datenbank ist das Lager, und bei Supabase hat das Lager mit Absicht eine eigene Tür zur Straße, damit deine Ladenfront von dort holen kann, ohne einen Lieferdienst dazwischen. Diese Tür ist das, was dir erspart, ein Backend zu schreiben.

Was bedeutet, dass die Tür öffentlich ist und ihre Adresse in deiner App steht, weil deine App an sie klopfen muss. Es gibt keine Anordnung, in der diese Adresse geheim wäre. Die Frage war also nie „können Fremde meine Datenbank erreichen". Sie können es, so ist es gebaut. Die Frage ist, was sie ihnen aushändigt, wenn sie fragen.

Gehört der Supabase-Schlüssel in meiner App dorthin?

Einer davon ja. Der andere nie, und sie sehen fast identisch aus.

Der öffentliche Schlüssel (sb_publishable_… in neuen Projekten, anon in älteren) sagt, zu welchem Projekt eine Anfrage gehört. Er trägt selbst keine Rechte, weshalb Supabases eigene Dokumentation ihn als unbedenklich beschreibt, um ihn in Webseiten und mobile Apps zu bündeln. Ihn in deiner App zu finden ist kein Befund.

Der geheime Schlüssel, sb_secret_… oder das ältere service_role, ist das Gegenteil. Er umgeht deine Regeln vollständig und liest und schreibt jede Zeile in jeder Tabelle, von überall. Er gehört auf einen Server, in eine Edge Function, in einen Worker: nirgendwohin, wo ein Browser hinkommt.

Sie liegen auf derselben Dashboard-Seite nebeneinander und haben dieselbe Form. Wurde einer je in Frontend-Code eingefügt, tausche ihn im Dashboard aus, bevor du irgendetwas änderst, denn die Zeile zu löschen schließt die Tür nicht.

Diese Seite ist Settings, dann API Keys, und dort stehen vier Werte statt zwei.

Die Einstellung, die entscheidet, was die Tür aushändigt

Row Level Security: ein Schalter pro Tabelle, der Zeile für Zeile entscheidet, wer was lesen darf. Sie ist der ganze Grund, warum ein öffentlicher Schlüssel unbedenklich ist.

Ist sie aus, gibt dieser Schlüssel jedem, der fragt, die ganze Tabelle. Ist sie an und eine Policy geschrieben, filtert die Datenbank selbst jede Anfrage, einschließlich Anfragen, die nie durch deine App gingen.

Zwei Details entscheiden, ob du sie tatsächlich hast, und keines ist aus deiner App heraus sichtbar:

Wie die Tabelle entstanden ist. Supabase aktiviert Row Level Security automatisch für Tabellen, die im Table Editor des Dashboards gemacht wurden. Tabellen, die per SQL angelegt werden, bekommen sie nicht und müssen bewusst aktiviert werden. Migrationsdateien, Skripte und KI-erzeugte Schemata legen Tabellen alle per SQL an, und ein so gebautes Projekt kann also eine Reihe ungeschützter Tabellen haben, die genau wie die geschützten aussehen.

Was die Policy sagt. Aktiviert heißt zu, bis eine Policy sie öffnet. Eine Policy, die alle durchlässt, öffnet sie ganz, während das Dashboard die Tabelle weiterhin mit aktivierter Row Level Security meldet, der Zustand, der geschützt aussieht und es nicht ist.

Storage ist noch einmal getrennt. Ein öffentlicher Bucket ist für jeden mit deiner Projektadresse auflistbar und herunterladbar, was auch immer deine Tabellenregeln sagen.

So prüfst du dein eigenes Supabase-Projekt in etwa zehn Minuten

Authentication → Policies. Lies die ganze Liste. Jede Tabelle, die Row Level Security als deaktiviert zeigt, ist für jeden lesbar. Bei den Tabellen, die sie als aktiviert zeigen, öffne die Policy und lies, was sie tatsächlich erlaubt.

Settings → API. Bestätige, dass der Schlüssel, den deine App ausliefert, der öffentliche ist. War je ein geheimer Schlüssel im Frontend-Code, tausche ihn hier zuerst aus. Zeigt dein Dashboard Schlüssel, die mit sb_publishable_ und sb_secret_ beginnen statt mit anon und service_role, ist das das neuere Format, und dieselbe Regel entscheidet, welcher der beiden in deine App gehört.

Storage → Buckets. Prüfe, welche öffentlich sind, und ob das für die Dateien darin so gemeint war.

Und dann schau von außen. Alles oben ist das, was dein Dashboard als konfiguriert meldet. Was eine anonyme Anfrage tatsächlich zurückbekommt, ist eine andere Frage, und die beantwortet unser kostenloser Scan: Er fragt so, wie ein Fremder fragen würde, ohne eine einzige deiner Zeilen zu lesen, und gibt dir in etwa 20 Sekunden eine Note: prüfen, was deine App preisgibt.

Öffne Authentication → Policies und geh die Liste einmal durch. Die als deaktiviert markierten Tabellen sind die, mit denen man anfängt, und wenn du die ganze Fläche lieber als Liste durchgehst, ist die Sicherheits-Checkliste in 10 Minuten die Kurzfassung. Was du auch findest: Zu wissen, dass du die Daten zurückspielen kannst, zählt genauso viel wie sie abzuschließen, und das hängt ganz davon ab, was du sicherst.

Wenn es nicht davon abhängen soll, dass du daran denkst: So funktionieren automatische Supabase-Backups.