Wo du deine Supabase API-Keys findest: anon, service_role, URL

Irgendetwas hat nach deinem Supabase-Schlüssel gefragt. Eine Anleitung, ein Support-Thread oder eine KI, der du gesagt hast, sie solle deine App reparieren. Du öffnest das Dashboard, findest eine Seite mit einer Adresse und zwei oder drei Schlüsseln mit Namen wie anon und service_role, und jeder davon sieht aus, als könnte er die Antwort sein.

Oder es ist die andere Variante. Jemand hat deine Seite geöffnet, F12 gedrückt und dir gesagt, ein Schlüssel sei sichtbar. Jetzt willst du dir ansehen, welchen Schlüssel diese Person gefunden hat, und weißt nicht, wo er liegt.

Die meisten Anleitungen fangen auf der Seite mit den API-Keys an. Das setzt voraus, dass du schon weißt, welches Supabase-Projekt deines ist, und genau diesen Schritt hat ein Builder für dich erledigt und nie erklärt.

Wo finde ich die Supabase API-Keys?

Im Dashboard, in deinem Projekt, unter Settings → API Keys.

Der ganze Weg: bei supabase.com anmelden, dein Projekt aus der Liste wählen, links in der Seitenleiste Settings öffnen, dann API Keys. Fast jede Anleitung und jeder Screenshot nennt diese Seite Settings → API, weil sie bis vor Kurzem so hieß. Es ist dieselbe Seite mit denselben Werten.

Alles darauf ist eines von zwei Dingen. Eine Adresse, die sagt, wo dein Projekt liegt. Oder ein Schlüssel, der entscheidet, was eine Anfrage dort tun darf. Die Seite listet beides zusammen auf, in einer Spalte, in derselben Schrift.

Ich habe Supabase nie eingerichtet. Welches Projekt ist meins?

Lies die Adresse, die deine App ohnehin schon benutzt. Die Antwort steckt darin.

Jedes Supabase-Projekt hat eine Referenz: eine kurze zufällige Zeichenfolge, die zugleich der erste Teil der Projektadresse ist, https://yourreference.supabase.co. Deine App schickt bei jedem Seitenaufruf eine Anfrage an diese Adresse, die Zeichenfolge steht also längst in deiner App, und es ist dieselbe, mit der das Dashboard dein Projekt benennt.

Drei Orte, an denen du sie findest, ohne jemanden zu fragen:

• In deinem Builder. Lovable, Bolt, v0 und die anderen zeigen das verbundene Supabase-Projekt irgendwo in den Einstellungen oder im Integrationsbereich deines Projekts.
• In deinem Browser. Öffne deine Live-App, drücke F12, wechsle auf den Tab Network und lade die Seite neu. Die Anfragen an irgendetwas mit .supabase.co tragen die Referenz in ihrer Adresse.
• Im Quelltext der Seite, falls deine App die Adresse ins HTML schreibt und nicht in eine Skriptdatei.

Melde dich dann bei supabase.com an und gleiche diese Referenz mit deiner Projektliste ab. Builder verbinden Supabase über deinen eigenen Account, das Projekt liegt also meistens in einem Dashboard, für das du dich einmal registriert und das du nie benutzt hast. Sobald du in einem Projekt bist, steht die Referenz in der Adresszeile des Browsers, und so bestätigst du, dass du im richtigen bist, bevor du etwas herauskopierst.

Die vier Dinge auf dieser Seite

Eine Adresse und drei Schlüssel. Zwei davon gehören in deine App, zwei verlassen das Dashboard nie.

Auf der Seite selbst liegt eine Abkürzung. Supabase druckt Projekt-URL und öffentlichen Schlüssel dort hin, wo du sie lesen kannst, und verdeckt den geheimen Schlüssel und den JWT-Wert mit Punkten, bis du sie anzeigen lässt. Die beiden, die es verdeckt, sind genau die beiden, die nie in deine App gehören.

Wo finde ich meine Supabase-Projekt-URL?

An zwei Stellen, und eine davon hast du wahrscheinlich gerade vor dir. Das Dashboard druckt sie oben auf Settings → API Keys, beschriftet mit Project URL. Die Adresszeile deines Browsers zeigt dieselbe Zeichenkette, sobald deine App mit Supabase spricht, in der Form https://yourreference.supabase.co.

Im Code trägt sie einen von drei Namen, und alle drei halten dieselbe Zeichenkette:

• VITE_SUPABASE_URL in einer App mit Vite, was das meiste abdeckt, was Lovable und Bolt bauen
• NEXT_PUBLIC_SUPABASE_URL in einer Next.js-App
• SUPABASE_URL auf einem Server, in einer Edge Function oder in einem Skript

Der mittlere Teil, yourreference, ist deine Projektreferenz. Das ist die Zeichenkette, an der das Dashboard dein Projekt erkennt, und die, die du abgleichst, wenn du mehrere Projekte hast und nicht weißt, welches zu dieser App gehört.

Sie ist eine Adresse und kein Geheimnis, weshalb sie offen neben dem öffentlichen Schlüssel steht.

Wo ist der service_role-Schlüssel, und was ist SUPABASE_SERVICE_ROLE_KEY?

Auf derselben Seite wie alles andere. Öffne Settings → API Keys und suche die Zeile mit service_role, auf einem neu angelegten Projekt secret. Anders als die URL und der öffentliche Schlüssel liegt sein Wert hinter einem Aufdecken-Schalter, bis du danach fragst.

Dieser Schalter ist der einzige Hinweis, den dir das Dashboard darauf gibt, dass dieser hier anders ist, und er verdient Aufmerksamkeit: Supabase verdeckt genau die Werte, die niemals in einen Browser gehören.

SUPABASE_SERVICE_ROLE_KEY ist ein Variablenname statt eines zweiten Schlüssels: dahinter steht der Wert, den du eben aufgedeckt hast. Du triffst ihn in einer .env-Datei, in den Umgebungseinstellungen deines Hosters oder in den Secrets einer Edge Function. Entscheidend ist das Präfix davor. Eine Variable namens VITE_SUPABASE_SERVICE_ROLE_KEY oder NEXT_PUBLIC_SUPABASE_SERVICE_ROLE_KEY wird in das JavaScript kompiliert, das deine Besucher herunterladen, also ist der Schlüssel mit dem Deploy öffentlich. Diese Präfixe sind Anweisungen zu veröffentlichen, keine Versehen.

Hingehören tut er in eine Edge Function, einen Webhook-Handler, einen geplanten Job oder ein Migrationsskript: überall dort, wo der Code auf einer Maschine läuft, die du kontrollierst, und kein Besucher die Datei öffnen kann. Dieser Schlüssel übergeht Row Level Security vollständig, er liest also jede Zeile in jeder Tabelle, was deine Regeln auch sagen.

Wenn du nicht sicher bist, ob deiner auf dem Server geblieben ist: unser kostenloser Website-Sicherheitsscanner liest deine Live-Seite von außen und benennt die Schlüssel, die er findet, in etwa 20 Sekunden.

Welchen Schlüssel braucht meine App?

Die Projekt-URL und den öffentlichen Schlüssel. Sonst nichts, niemals.

Deine App läuft im Browser deiner Besucher und redet von dort aus mit Supabase, also gehen beide Werte von Haus aus an jeden Besucher. Das ist kein Leck und war nie eines. Was einen Fremden davon abhält, mit einem öffentlichen Schlüssel deine ganze Datenbank zu lesen, ist Row Level Security: die Regeln, die Zeile für Zeile entscheiden, wer was sehen darf.

Diese Regeln sind also das, was du prüfen solltest, wenn du dir Sorgen machst, und sie einzuschalten ist nicht dasselbe wie geschützt zu sein. Die ausführliche Fassung davon, warum ein Schlüssel öffentlich sicher ist, steht in welche API-Schlüssel im Frontend sicher sind.

Woher weiß ich, welcher Schlüssel wirklich in meiner App gelandet ist?

Aus dem Dashboard erfährst du das nicht. Es listet die Schlüssel auf, die dein Projekt hat, nicht den, der in deine App gewandert ist.

Das sind zwei verschiedene Fragen, und nur die zweite kann dir wehtun. Ein Projekt kann eine völlig gewöhnliche Einstellungsseite haben und trotzdem seinen geheimen Schlüssel in einer Datei stehen haben, die jeder öffnen kann. Um das zu beantworten, musst du den Schlüssel lesen, der tatsächlich in der App steht.

In einem neueren Projekt liest du die ersten Zeichen. sb_publishable_ ist der, der dort hingehört. sb_secret_ ist der, um den du dich heute kümmern solltest.

In einem älteren Projekt musst du in den Schlüssel hineinschauen. anon und service_role sind JWTs: drei durch Punkte getrennte Blöcke, deren mittlerer zu lesbarem Klartext wird. Darin steht ein Feld role, und dieses eine Wort ist der gesamte Unterschied zwischen beiden. Wie du es liest.

Wenn du deine App nicht von Hand durchgehen willst: unser kostenloser Scan liest deine Live-Seite von außen und benennt die Schlüssel, die er sehen kann, und ob deine Tabellen einem Fremden antworten, der fragt. Das dauert etwa 20 Sekunden und braucht kein Konto: App scannen.

Was, wenn der geheime Schlüssel schon in meiner App steckt?

Kümmere dich um den Schlüssel selbst, bevor du Code anfasst, und bei Supabase heißt das womöglich nicht, was du erwartest.

Der übliche Rat lautet rotieren: neuen Schlüssel erzeugen, alten zurückziehen, und der Wert, der nach außen gelangt ist, funktioniert nicht mehr. Für die neueren Schlüssel gilt das weiterhin. Ein Projekt kann mehrere sb_secret_-Schlüssel gleichzeitig halten und sie einzeln zurückziehen, ein Austausch bedeutet also keine Minute mehr, in der alles kaputt ist, was ihn benutzt.

Für das ursprüngliche Paar gilt es überhaupt nicht. Supabase schreibt in den eigenen Fehlerbehebungs-Notizen, dass sich die alten anon-, service_role- und JWT-Geheimnisse nicht mehr rotieren lassen. Einen geleakten alten service_role-Schlüssel unbrauchbar zu machen heißt: neue Schlüssel anlegen, App und Servercode darauf umstellen und dann das alte Paar deaktivieren. Was diese Migration umfasst, sind eine Handvoll Schritte im Dashboard und ein ausgetauschter Wert in deiner App, und das geht an einem ruhigen Nachmittag deutlich leichter als an dem Tag, an dem du es brauchst.

Was jetzt zu tun ist

Wenn du das lieber als Liste durchgehst: die 10-Minuten-Sicherheitscheckliste deckt das ab und dazu die anderen Dinge, die man in einer frisch gestarteten App abschalten sollte, und wir haben eine Anleitung in einfacher Sprache für Supabase-Apps.