Der Key im Frontend ist selten das Problem

Wer eine App mit Lovable, Bolt oder Replit baut, bekommt eine Warnung früher oder später von irgendwo her: Da steht ein Key im Quelltext! Im Browser kann das jeder sehen.

Stimmt. Und meistens ist es trotzdem in Ordnung.

Bei Supabase zum Beispiel ist der Publishable Key (früher: anon Key) dafür gedacht, im Browser zu liegen. Jeder darf ihn lesen. Er kann nur das, was die Zugriffsregeln der Datenbank erlauben. Gefährlich wird es beim Secret Key, früher service_role. Der umgeht diese Regeln komplett. Steht der im Frontend, ist die Datenbank offen. Beides sieht auf den ersten Blick ähnlich aus, ein langer Schlüssel eben. Der Unterschied ist trotzdem der ganze Punkt.

Wir bauen LaunchCheck, einen Check für genau diese Apps. Dabei prüfen wir in einer festen Reihenfolge: nicht was falsch aussieht, sondern was wirklich Schaden anrichten kann.

Erstens: die Regeln hinter dem Key

Ein öffentlicher Key ist nur so harmlos wie die Zugriffsregeln, die an ihm hängen. Bei Supabase heißt das Row Level Security, bei Firebase Security Rules. Laut Supabase-Doku kann eine Tabelle in einem öffentlich erreichbaren Schema ohne diese Regeln von jeder Rolle gelesen und beschrieben werden, die einen Grant darauf hat. Und neue Tabellen bekommen standardmäßig erst mal alle Rechte. Das ist kein Bug, das ist ein Default. Wer ihn nicht kennt, veröffentlicht eine Datenbank, die jeder mit dem öffentlichen Key lesen kann.

Bei Firebase ist es das gleiche Muster in anderer Form: allow read, write: if true. Praktisch im Testmodus. Fatal im Livebetrieb. Die Regeln sind dort bei direktem Zugriff aus dem Client die einzige Schutzschicht, so steht es sinngemäß in der Firebase-Doku.

Zweitens: was der Server dazu sagt

Security-Header sind unspektakulär. Deshalb fehlen sie. Auf Vercel setzt man sie in der vercel.json, bei Netlify in einer _headers-Datei oder in der netlify.toml. Eine Content-Security-Policy würden wir nie direkt scharf schalten, sondern erst im Report-Only-Modus laufen lassen und nachsehen, was sie blockieren würde. Sonst bricht die Seite am Launchtag, und das will niemand.

Und dann gibt es noch die Dateien, die nie im Auslieferungsordner liegen sollten. Eine .env oder ein .git-Ordner im veröffentlichten Verzeichnis gehört dazu. Wer das vermutet, kann es in dreißig Sekunden selbst prüfen: Adresse plus /.env in den Browser. Die erwartete Antwort ist ein 404.

Drittens, und das wird gern vergessen: die Seiten, die kein Code sind

Impressum. Datenschutzerklärung. Wer in Deutschland oder Österreich eine App an Menschen ausliefert, braucht beides, und zwar nicht erst nach dem ersten Abmahnschreiben. Dazu kommt, was die App im Hintergrund lädt. Google Fonts von Googles Servern, ein Analytics-Skript, ein Chat-Widget. Das braucht je nach Setup eine Einwilligung. Wir geben dazu keine Rechtsberatung, das sagen wir auch in jedem Ratgeber dazu. Wir sagen nur: Schaut vorher hin.

Zurück zum Key

Wenn ihr heute einen in eurem Quelltext findet, dann klärt zuerst, welcher es ist. Beginnt er mit sb_publishable_ oder ist es ein altes anon-Token, ist das erwartbar. Ist es ein sb_secret_ oder ein Token mit der Rolle service_role, habt ihr einen Notfall. Dann zuerst die Ursache beheben, also alles, was den Key braucht, ins Backend verlegen. Erst danach einen neuen Key anlegen, überall austauschen und den alten löschen. Die Reihenfolge ist wichtig, und sie steht so auch in der Supabase-Doku.

Was wir daraus mitnehmen: Der sichtbare Key ist ein Symptom, das man schnell sieht. Die fehlende Regel dahinter sieht man nicht. Genau da lohnt sich der Blick, bevor die App live geht.

Wenn ihr wissen wollt, wie eure App von außen aussieht: launchcheck.de prüft passiv, ohne Login und ohne etwas an eurer App zu verändern.

Quellen: Supabase-Doku „API keys“ (supabase.com/docs/guides/api/api-keys) und „Row Level Security“ (supabase.com/docs/guides/database/postgres/row-level-security); Firebase-Doku „Security Rules basics“ (firebase.google.com/docs/rules/basics); Vercel „Content Security Policy“ (vercel.com/docs/cdn-security/security-headers); Netlify „Headers“ (docs.netlify.com/manage/routing/headers/).

Verwandte Artikel: AI-native Entwicklung ohne System: drei Muster und Vibe Coding ist eine Methode, kein Glücksspiel.