Supabases neue API-Schlüssel: welcher gehört in deine App?

Wenn du kürzlich dein Supabase-Dashboard geöffnet und dort Schlüssel gefunden hast, die mit sb_publishable_ und sb_secret_ beginnen, wo früher anon und service_role standen: Es ist nichts kaputt. Supabase hat seine API-Schlüssel umbenannt, und das Paar, das du kennst, ist auf dem Weg nach draußen.

Die Änderung ist klein in dem, was sie tut, und groß in dem, was sie verhindert. Die beiden Schlüssel erledigen weiterhin genau die zwei Aufgaben, die sie immer hatten. Neu ist, dass du jetzt ohne Umweg siehst, welcher welcher ist.

Was Supabase tatsächlich geändert hat

Supabase hat die neuen Schlüssel im Juli 2025 angekündigt, zusammen mit einer Änderung daran, wie Anmeldetokens signiert werden. Zwei Dinge haben zwei Dinge ersetzt:

• Der öffentliche Schlüssel, sb_publishable_…, ersetzt den anon-Schlüssel.
• Geheime Schlüssel, sb_secret_…, ersetzen den service_role-Schlüssel.

An den Rechten ändert sich nichts. Ein öffentlicher Schlüssel benennt weiterhin nur dein Projekt und trägt keine eigenen Rechte; ein geheimer umgeht weiterhin jede Regel, die du geschrieben hast. Wenn du schon weißt, welche Schlüssel im Frontend sicher sind, ist an diesem Wissen nichts falsch geworden.

Zwei praktische Unterschiede lohnen sich zu kennen. Du kannst mehrere geheime Schlüssel gleichzeitig haben und sie einzeln widerrufen. Rotieren bedeutet also nicht mehr einen Moment, in dem alles kaputt ist, was den Schlüssel benutzt hat. Und die alten Schlüssel hatten eine Eigenschaft, die kaum jemandem auffiel: Sie waren JWTs, die zehn Jahre nach dem Anlegen des Projekts ablaufen. Die neuen tragen kein Ablaufdatum in sich.

Welcher der beiden in deine App gehört

Der öffentliche, und nur der öffentliche.

Deine App läuft im Browser deiner Besucherin, und die Anfrage an deine Datenbank geht von dort los. Sie muss sagen, zu welchem Projekt sie gehört, und diese Kennung erreicht jede Besucherin, so ist es gedacht. sb_publishable_… ist der Schlüssel, der genau dafür gebaut ist: Ihn in deiner App zu finden ist kein Befund, und war es nie.

sb_secret_… ist das Gegenteil. Er liest und schreibt jede Zeile in jeder Tabelle, von überall, und ignoriert deine Policies vollständig. Das ist sein ganzer Zweck. Er gehört auf einen Server, in eine Edge Function, in einen Worker: nirgendwohin, wo ein Browser hinkommt. Ist einer je in Frontend-Code gelandet, tausche ihn im Dashboard aus, bevor du sonst etwas änderst. Die Zeile zu löschen schließt die Tür nicht.

So erkennst du, welche Sorte du hast

Lies die ersten Zeichen. Das ist inzwischen die ganze Prüfung.

Ein aktueller Schlüssel ist eine lange Zeichenkette aus zwei Hälften: einer zufälligen Mitte und einer kurzen Prüfsumme am Ende. Ein alter Schlüssel besteht aus drei durch Punkte getrennten Blöcken, und der mittlere ist lesbarer Text statt Verschlüsselung. Deshalb hieß es beim alten Paar, ihn zu dekodieren und das Feld role zu lesen.

Wenn du einen Schlüssel in deiner App findest und nicht weißt, welcher es ist: Unser kostenloser Scan liest deine Live-Seite von außen und benennt, was er sehen kann. Das dauert etwa 20 Sekunden und braucht kein Konto: App scannen.

Funktionieren meine alten anon- und service_role-Schlüssel noch?

Heute ja. Supabase hat einen Zeitplan veröffentlicht, keinen Ausschalter:

Es gibt also diese Woche keinen Notfall, und es gibt dieses Jahr eine Frist. Wenn deine App vor der Umbenennung gebaut und seither nicht angefasst wurde, läuft sie gerade auf alten Schlüsseln und wird das noch eine Weile tun.

Das Argument für einen frühen Wechsel ist nicht die Frist. Es ist der Tag, an dem jemand den falschen Schlüssel in einen Prompt einfügt: sb_secret_ sagt laut, was es ist, eyJ… nicht.

So wechselst du, ohne deine App zu zerlegen

Supabases eigene Migrationsanleitung ist die Referenz. Die Kurzfassung für eine App, die du nicht von Hand geschrieben hast:

1. Öffne im Dashboard Settings → API Keys und erzeuge die neuen Schlüssel. Das legt sie zusätzlich an; die alten verschwinden nicht, und beide Paare funktionieren gleichzeitig.
2. Finde die Stelle, an der deine App ihren Supabase-Client erzeugt, und ersetze den öffentlichen Schlüssel. In einem Builder wie Lovable oder Bolt ist das meist ein Wert in den Projekteinstellungen statt einer Codezeile.
3. Ersetze den geheimen Schlüssel überall, wo er auf einem Server benutzt wird: Edge Functions, Webhooks, geplante Jobs, alles, was nicht der Browser ist.
4. Lade deine App und klick dich durch die Stellen, die Daten lesen und schreiben. Ein falscher öffentlicher Schlüssel scheitert sofort und laut, und das ist der gute Fall.
5. Erst wenn alles läuft, schalte die alten Schlüssel ab.

Schritt 5 gehört ans Ende, und man sollte ihn bewusst gehen statt nie: Halb migrierte Projekte, in denen die App noch einen alten anon-Schlüssel neben einem aktiven sb_publishable_ trägt, sind häufig und im Fehlerfall verwirrend.

Was diese Woche zu tun ist

Wenn du die plattformspezifische Fassung möchtest, was zu prüfen ist: Wir haben eine verständliche Anleitung für Supabase-Apps, und die Sicherheits-Checkliste in 10 Minuten deckt diesen Punkt neben den anderen Dingen ab, die man in einer frisch veröffentlichten App abschalten sollte.