Service-Role-Key (Supabase)
Der Service-Role-Key ist Supabases Generalschlüssel: Er umgeht jede Row-Level-Security-Regel und darf jede Zeile lesen, ändern und löschen. Er gehört ausschließlich auf den Server. Landet er im Frontend-Code, in einer NEXT_PUBLIC-Variable oder im Browser-Bundle, kann jeder Besucher die komplette Datenbank auslesen und überschreiben — unabhängig davon, wie gut die restliche App gesichert ist.
Supabase gibt euch zwei Schlüssel: den Anon-Key (öffentlich, an RLS gebunden) und den Service-Role-Key (privat, RLS-frei). Der Anon-Key darf ins Frontend — er sieht nur, was eure RLS-Policies erlauben. Der Service-Role-Key darf das nie, weil er alle Regeln aushebelt. Diese Unterscheidung ist der häufigste kritische Fehler in KI- und No-Code-generierten Apps.
Der typische Weg ins Leck: Ein Generator oder ein Tutorial legt den Key in eine Variable mit dem Präfix NEXT_PUBLIC_ (Next.js) oder VITE_ (Vite) — beide werden fest ins ausgelieferte Browser-Bundle kompiliert. Wer die Seite öffnet und in die Developer-Tools schaut, hat den Generalschlüssel. Ab dann ist die Datenbank offen, egal wie stark das Passwort ist.
Prüft es selbst: Der Service-Role-Key darf nur in serverseitigem Code stehen (API-Routen, Server Actions, Edge Functions) und in Umgebungsvariablen ohne NEXT_PUBLIC-/VITE-Präfix. Sucht im gesamten Frontend-Bundle nach „service_role“. Genau diesen Fund macht unser Rescue-Deep-Scan sichtbar — er ist einer der Findings, die eine App sofort auf „Stopp“ setzen.