Supabase-Key öffentlich im Code: ist das schlimm?

Der Unterschied

Supabase beschreibt den Publishable Key so: Jeder kann ihn lesen, er erreicht nur, was Row Level Security erlaubt. Der Secret Key umgeht Row Level Security und darf die eigene Kontrolle nie verlassen. Policies greifen bei ihm nicht, weil seine Postgres-Rolle das Attribut BYPASSRLS hat.

Bei älteren Projekten heißen die Schlüssel anon und service_role und sind lange Tokens, die mit eyJ beginnen. Supabase weist darauf hin, dass ein langer Schlüssel mit eyJ zu diesen älteren Schlüsseln gehört.

Was daraus folgt

Aktiviert Row Level Security auf jeder Tabelle, bevor ihr veröffentlicht. Ohne Row Level Security kann der öffentliche Key mehr, als ihr denkt.

So erkennt ihr, welcher Key im Bundle steht

Öffnet den Quelltext der veröffentlichten Seite und sucht nach supabase.co und nach den Schlüsseln: sb_publishable_, sb_secret_ und bei älteren Projekten nach einem langen eyJ…-Token. Ein eyJ…-Token mit der Rolle service_role ist der Notfall. Der Check erkennt ein solches service_role-Token im älteren Format automatisch. Nach sb_secret_ sucht er derzeit nicht, das prüft ihr selbst.

Wenn ein Secret Key öffentlich war

Behebt zuerst die Ursache: Verlegt alles, was den Secret Key braucht, ins Backend. Supabase rät, nicht zu hetzen und die Ursache vor der Rotation zu beseitigen. Legt dann einen neuen Secret Key an und ersetzt den alten überall. Prüft, dass jede Stelle den neuen Key nutzt, und löscht erst danach den alten. Das Löschen lässt sich nicht rückgängig machen. So ist die Reihenfolge in der Supabase-Doku beschrieben.

Typische Fehler

Die Supabase-Doku warnt vor diesen Fehlern im Umgang mit Keys:

• Den Secret Key im Browser verwenden. Laut Doku gehört er nur in Backend-Bausteine wie Server, APIs mit eigener Autorisierung, Edge Functions und Microservices. Im Browser lehnt Supabase ihn mit HTTP 401 ab.
• Den Secret Key ins Repository, in CI-Skripte, in Chat, E-Mail oder SMS oder in eine URL legen. Die Doku rät, Schlüssel in der Secrets-Ablage des jeweiligen Werkzeugs zu halten. Auch in Logs gehört er nicht vollständig: höchstens 6 Zeichen nach dem Präfix.
• Den Key im Header Authorization: Bearer schicken. Publishable und Secret Key sind keine JWTs und gehören in den Header apikey.
• Beim Umstieg auf die neuen Schlüssel vergessen, dass Supabase die alten (anon und service_role) als veraltet einstuft. Das Abschalten der alten Schlüssel ist ein eigener Schritt.

Beispiel: welcher Key wohin

Die Zuordnung nach der Supabase-Doku:

• Browser und ausgelieferte Apps: Publishable Key (sb_publishable_…). Er darf öffentlich sein, weil er nur erreicht, was Row Level Security erlaubt.
• Server, Edge Functions und andere Backend-Bausteine: Secret Key (sb_secret_…), aus der Secrets-Ablage, nie aus dem Code.
• Lokale Entwicklung: supabase start gibt einen Publishable Key und einen Secret Key für das lokale Projekt aus. Sie gehören nicht zum gehosteten Projekt.

Häufige Fragen