Zugangsdaten
API-Schlüssel im Frontend: warum KI-Code sie so oft offenlegt
Ein API-Schlüssel ist ein Passwort für einen Dienst, und meist auch für Ihr Konto dort. In KI-generierten Anwendungen steht er erstaunlich oft im Code, den jeder Besucher herunterlädt. Woran Sie das erkennen und was Sie tun, wenn es schon passiert ist.
Wie der Schlüssel in den Browser kommt
Sie bitten die KI, eine Funktion mit einem KI-Dienst, einem Zahlungsanbieter oder einem Mail-Dienst einzubauen. Der kürzeste Weg: Die Oberfläche ruft den Dienst direkt auf und schickt den Schlüssel mit. Das funktioniert sofort, und genau deshalb wählt die KI diesen Weg.
Der Haken: Alles, was im Frontend steht, lädt der Browser jedes Besuchers herunter. Ein Blick in die Entwicklerwerkzeuge genügt, um den Schlüssel zu lesen. Automatische Scanner durchsuchen öffentliche Websites und Repositories laufend nach solchen Schlüsseln.
Die Umgebungsvariable, die keine Geheimhaltung bringt
Viele denken, ein Schlüssel in einer .env-Datei sei geschützt. Das stimmt nur für Code, der auf dem Server läuft. Variablen mit Präfixen wie VITE_ oder NEXT_PUBLIC_ werden beim Bauen absichtlich in den Browser-Code geschrieben. Steht dort ein geheimer Schlüssel, ist er öffentlich.
Öffentliche und geheime Schlüssel
Nicht jeder Schlüssel im Frontend ist ein Fehler. Manche Dienste unterscheiden ausdrücklich:
- Supabase: Der anon- bzw. publishable Key darf öffentlich sein, sofern die Datenbankrechte stimmen. Der service_role- bzw. secret Key umgeht alle Rechte und darf nie in den Browser.
- Stripe: Der Publishable Key ist für das Frontend gedacht, der Secret Key nie.
- KI-Dienste wie OpenAI oder Anthropic: Es gibt keinen öffentlichen Schlüssel. Jeder Schlüssel im Browser ist ein Fehler.
Dass ein öffentlicher Schlüssel nur so sicher ist wie die Regeln dahinter, zeigt der Artikel Datenbankrechte bei Supabase und Firebase.
So prüfen Sie Ihre Anwendung
- Öffnen Sie Ihre Anwendung, dann die Entwicklerwerkzeuge des Browsers.
- Durchsuchen Sie unter „Quellen“ bzw. „Sources“ alle geladenen Dateien nach
sk-,secret,service_roleundapi_key. - Beobachten Sie unter „Netzwerk“, welche Anfragen direkt an externe Dienste gehen und was im Kopf der Anfrage mitgeschickt wird.
- Prüfen Sie Ihr Repository einschliesslich der Versionsgeschichte, etwa mit dem kostenlosen Werkzeug gitleaks oder dem Secret Scanning von GitHub.
Wenn ein Schlüssel schon öffentlich war
Löschen reicht nicht. Ein Schlüssel, der einmal im Browser-Code oder in einem Repository stand, gilt als bekannt. Erstellen Sie beim Anbieter einen neuen Schlüssel, sperren Sie den alten und prüfen Sie die Nutzung der letzten Wochen auf Auffälligkeiten. Danach bauen Sie den Aufruf so um, dass er über eine Serverfunktion läuft, die den Schlüssel kennt, die Oberfläche aber nicht.
Den Umbau richtig beauftragen
Bitten Sie die KI ausdrücklich: „Verschiebe alle Aufrufe an diesen Dienst in eine Serverfunktion. Der Schlüssel darf nur dort stehen. Die Funktion prüft, ob der Aufrufer angemeldet ist, und begrenzt die Zahl der Aufrufe.“ Ohne den letzten Satz entsteht leicht eine offene Funktion, die jeder beliebig oft aufrufen kann. Das ist Lücke Nummer vier im Überblick über die häufigsten Sicherheitslücken.
Bevor Sie damit live gehen
Ihre Lösung läuft. Diese Punkte sollten Sie prüfen, bevor echte Daten daran hängen:
- Steht irgendein geheimer Schlüssel im Code, den der Browser lädt?
- Liegen Schlüssel in der Versionsgeschichte Ihres Repositorys?
- Prüft jede Serverfunktion, wer sie aufruft und wie oft?
Sie wollen sicher sein? Das Vibe-Code-Review prüft genau diese Grundlagen. Mehr zum Review →
Lieber selbst anfangen? Die kostenlose Schnellprüfung aus dem Vibecode-Testing-Kit zeigt Ihnen, wo Sie stehen. Zur Schnellprüfung →
Sie haben schon gebaut? Lassen Sie es prüfen.
Beschreiben Sie Ihr Produkt in ein paar Sätzen. Ich melde mich persönlich.