Zum Inhalt springen
← Alle Beiträge

4. September 2026

Du versteckst den falschen Schlüssel

Der öffentliche Supabase-Schlüssel gehört in die App, der ist mit Absicht öffentlich. Der geheime umgeht jede Zugriffsregel. Vier Orte, an denen er nicht landen darf.

Jemand postet in einer Community einen Screenshot: Der Schlüssel der Datenbank steht offen im Netzwerk-Verkehr der App, für jeden Besucher lesbar. Die Frage darunter: Wie kriege ich den da raus? Die Antworten: Zwischenserver bauen, alles umziehen, aufwendig absichern.

Der ganze Aufwand ist umsonst. Dieser Schlüssel gehört genau dahin.

Der öffentliche Schlüssel ist zum Veröffentlichen da

Supabase nennt ihn “publishable key”, veröffentlichbarer Schlüssel. Die Doku schreibt, dass er für Umgebungen gedacht ist, in denen sich kein Geheimnis schützen lässt: Webseiten und Apps. Jeder kann ihn auslesen. Das ist eingeplant.

Er sagt nur, welches Projekt gemeint ist. Was ein Besucher sehen darf, entscheiden die Zugriffsregeln. Wer den öffentlichen Schlüssel versteckt, ist an der falschen Stelle nervös. Die richtige Stelle beschreibt der Post RLS an heißt nicht abgesichert.

Der andere Schlüssel im selben Dashboard

Direkt daneben liegt der zweite, der geheime Schlüssel. Er umgeht laut Supabase jede Zugriffsregel, “any and all”, auch die, an der du gestern eine Stunde gesessen hast. Mit ihm sieht und ändert man alle Daten aller Nutzer.

Deshalb gilt eine kurze Regel: Er liegt auf einem Server, den du kontrollierst, und sonst nirgends. Die Doku formuliert es härter: “Never use in a browser.”

Beim Vibe Coding legt ihn niemand absichtlich in die App. Er rutscht dahin. Ein Feature funktioniert nicht, die KI vermutet ein Rechteproblem, du gibst ihr den geheimen Schlüssel zum Testen, sie schreibt ihn in eine Datei. Das Feature läuft. Die Datei bleibt.

Der Handgriff: such ihn

Es sind vier Orte, an denen der geheime Schlüssel häufig landet. Dein Entwickler oder die KI kann sie in zehn Minuten durchsuchen. Frag konkret nach diesen vier:

1. In der fertigen App. Alles, was in der ausgelieferten App steckt, kann jeder Besucher herunterladen. Steht dort der geheime Schlüssel, ist er ausgeliefert. Keine Fundstelle ist das gute Ergebnis.

2. In der Versionsgeschichte. Eine Datei mit Schlüsseln zu löschen entfernt sie nicht aus der Vergangenheit. Jede frühere Version bleibt gespeichert. Auch dort muss die Suche laufen.

3. In falsch benannten Variablen. Manche Werkzeuge bauen bestimmte Einstellungen fest in die App ein, sobald sie mit einem bestimmten Namensanfang beginnen. Next.js beschreibt das so. Ein geheimer Schlüssel mit so einem Namen ist öffentlich, egal wie geheim er gemeint war.

4. In den Protokollen. Beim Fehlersuchen gibt Code gern alles aus, was er kennt. Diese Ausgabe landet im Protokoll, und der Eintrag bleibt dort liegen. Der schlimmste Fund ist eine Ausgabe, die den kompletten Schlüsselbund ins Protokoll kippt.

Wenn etwas gefunden wird

Dann ist der Schlüssel verbrannt und wird ausgetauscht. Im Dashboard legst du einen neuen an, trägst ihn überall ein und löschst erst danach den alten. Supabase weist darauf hin, dass Löschen endgültig ist.

Hängst du noch an einem alten Schlüssel, ist der Weg länger. Die alten Schlüssel laufen ohnehin Ende 2026 aus, das Thema steht also sowieso auf deiner Liste.

Drei Stellen, die keine Suche findet

Der Chat mit der KI. Beim Debuggen kopierst du Einstellungen in den Prompt, oder du schickst einen Screenshot vom Dashboard mit sichtbarem Schlüssel. Der liegt jetzt in einem Gesprächsverlauf, über den du nicht bestimmst. Nach so einem Moment tauschst du den Schlüssel, auch wenn nichts Sichtbares passiert ist. Das kostet fünf Minuten.

Die Protokolle beim Veröffentlichen. Eine Ausgabe zur Fehlersuche im Build-Ablauf schreibt den Wert ins Protokoll, und jeder mit Zugriff aufs Projekt liest ihn mit.

Die Datei, die du für Server-Code hältst. Manchmal landet Code, den du auf dem Server glaubst, doch in der App. Deshalb ist die Prüfung der fertigen App der wichtigste Schritt. Deine Ordnerstruktur ist eine Absicht, die fertige App ist das Ergebnis. Geprüft wird das Ergebnis.

Wo es danach weitergeht

Die vier Orte oben finden den Schlüssel dort, wo er am häufigsten landet. Ein vollständiges Sicherheitsbild sind sie nicht. Wer welche Rechte im Projekt hat, welche Funktion mit welchem Schlüssel arbeitet, welche Tabelle über einen Umweg trotzdem offen liegt: Das steht auf anderen Blättern.

Im Supabase-Guide liegt die geordnete Aufstellung, von den Schlüsseln über die Zugriffsregeln bis zu den Stellen, an denen Projekte im echten Betrieb kippen.

Wenn du diese Woche nur eine Sache machst: Lass die fertige App einmal nach dem geheimen Schlüssel durchsuchen.

Michael Schreier
Michael Schreier

Diplom-Informatiker · 25 Jahre Entwicklung · LinkedIn

supabasesicherheitvibe-codingki
praxis-guides
$ guide --open "Supabase Best Practice"
[i] RLS, Auth und Realtime stehen so, dass dein Projekt in Produktion nicht an den bekannten Stellen umkippt.

PDF plus Beispiele · 239 € inkl. MwSt. (200,84 € netto) · framework-unabhängig

Supabase Best Practice
Michael Schreier

Fragen zum Thema?

Schreib mir — ich freue mich auf den Austausch.