So schützt du API-Schlüssel in deiner App

Um API-Schlüssel sicher zu halten, speicherst du sie als Geheimnisse oder Umgebungsvariablen auf deinem Host, nutzt sie nur im Code auf dem Server und fügst sie nie in Chats, Code-Dateien, Screenshots oder ein Git-Repository ein. Gib jedem Schlüssel nur die Rechte, die er braucht, setze Ausgabelimits beim Anbieter, und wenn ein Schlüssel doch einmal leakt, rotiere ihn: Erstelle einen neuen und lösche den alten. Den Ort, an dem er aufgetaucht ist, einfach zu verstecken, reicht nicht.

Ein API-Schlüssel ist ein Passwort für einen Dienst. Dein OpenAI-Schlüssel erlaubt jemandem, auf deine Kosten KI zu nutzen. Dein geheimer Stripe-Schlüssel erlaubt Rückerstattungen. Dein E-Mail-Schlüssel erlaubt, Mails in deinem Namen zu versenden. KI-Baukästen verdrahten diese Schlüssel gut, sind aber nicht immer sorgfältig damit, wo sie landen. Dieser Leitfaden zeigt, wie du sie schützt und wie du prüfst.

Öffentliche und geheime Schlüssel

Nicht jeder Schlüssel ist geheim. Wenn du den Unterschied kennst, gerätst du nicht wegen des falschen Schlüssels in Panik und übersiehst nicht den richtigen.

Wenn du nicht sicher bist, welche Art ein Schlüssel ist, schau in die Dokumentation des Anbieters. Im Zweifel behandle ihn als geheim.

Schritt 1: Schlüssel als Geheimnisse speichern, nicht im Code

Schlüssel gehören in die Umgebungsvariablen oder Geheimnis-Einstellungen deines Hosts. Dein Code liest sie zur Laufzeit über den Namen (zum Beispiel process.env.OPENAI_API_KEY), sodass der Wert nie in deinen Dateien steht. Den Hintergrund erklärt was Umgebungsvariablen und Geheimnisse sind.

Verschieb jeden API-Schlüssel aus dem Code in Umgebungsvariablen. Liste jeden Schlüssel auf, den du gefunden hast, in welcher Datei er stand und welchen Variablennamen du verwendet hast. Zeig mir die Werte nicht.

Prüf dann, ob nichts übrig ist:

Durchsuche das gesamte Projekt, einschließlich Konfigurationsdateien und aller .env-Dateien, nach allem, was wie ein API-Schlüssel oder ein Passwort aussieht. Nenne Datei und Zeile, nicht den Wert.

Schritt 2: Geheime Schlüssel nur auf dem Server nutzen

Das ist die wichtigste Regel. Alles, was der Browser erhält, kann ein Besucher lesen: Quelltext und JavaScript-Dateien sind in den Entwicklertools sichtbar.

Braucht die App also OpenAI, ruft der Browser deinen Server auf, und dein Server ruft OpenAI mit dem Schlüssel auf. Der Schlüssel verlässt den Server nie.

Der Chat ruft OpenAI direkt aus dem Browser auf. Verlege diesen Aufruf in eine Server-Route, die OPENAI_API_KEY aus der Umgebung liest. Der Browser soll nur unsere Route aufrufen. Verlange für die Route eine Anmeldung.

Achte auf eine häufige Falle bei Frontend-Frameworks: Variablen mit einem öffentlichen Präfix – VITE_ in Vite, NEXT_PUBLIC_ in Next.js – werden absichtlich in den Browser-Code eingebaut. Ein geheimer Schlüssel mit einem solchen Präfix ist offengelegt, auch wenn er „in einer Umgebungsvariablen“ steht.

Schritt 3: Prüfen, dass nichts leakt

Verlass dich nicht darauf, dass es funktioniert hat. Prüf die Live-Seite:

1. Öffne die veröffentlichte App im Browser.
2. Öffne die Entwicklertools und dann den Reiter Quellen oder Netzwerk.
3. Suche in allen Dateien nach den ersten Zeichen jedes geheimen Schlüssels (zum Beispiel sk_ oder sk-).
4. Prüf die Netzwerkanfragen der App. Eine Anfrage, die direkt vom Browser an einen kostenpflichtigen KI-Anbieter geht, ist ein Alarmsignal.

Findest du einen geheimen Schlüssel, verlege ihn auf den Server (Schritt 2) und rotiere ihn (Schritt 6), denn er war bereits öffentlich.

Schritt 4: Einschränken, was jeder Schlüssel darf

Viele Anbieter erlauben, Schlüssel zu begrenzen:

• Eingeschränkte Schlüssel, die nur das können, was deine App braucht. Stripe unterstützt beispielsweise eingeschränkte Schlüssel mit bestimmten Rechten.
• Domain- oder IP-Beschränkungen für Schlüssel, die öffentlich sein müssen, etwa Kartenschlüssel.
• Eigene Schlüssel pro App und pro Umgebung, damit ein Leak nicht alles offenlegt und das Widerrufen eines Schlüssels die anderen nicht bricht.
• Testschlüssel beim Bauen, Live-Schlüssel nur in der veröffentlichten App.

Schritt 5: Den Schaden begrenzen

Auch ein gut geschützter Schlüssel kann über deine eigene App missbraucht werden – etwa wenn jemand deine KI-Funktion tausendfach per Skript aufruft.

• Setze Ausgabelimits oder Warnungen bei jedem kostenpflichtigen Anbieter.
• Verlange Anmeldung für jede Funktion, die pro Aufruf Geld kostet.
• Füge ein Rate-Limit pro Nutzer hinzu. Siehe was Rate-Limiting ist.

Füge für /api/chat ein Limit von 30 KI-Anfragen pro Nutzer und Stunde hinzu. Zeig bei Erreichen eine klare Meldung. Lehne Anfragen von nicht angemeldeten Nutzern ab.

Schritt 6: Geleakte Schlüssel rotieren

Wenn ein geheimer Schlüssel an einer Stelle auftaucht, wo er nicht hingehört – in einer Chat-Nachricht, einem Commit, einem Screenshot, einem Support-Ticket, im Browser-Code –, geh davon aus, dass er kompromittiert ist.

1. Erstelle beim Anbieter einen neuen Schlüssel.
2. Aktualisiere das Geheimnis in den Einstellungen deiner App.
3. Deploy oder veröffentliche erneut, damit die Live-App den neuen Schlüssel nutzt.
4. Lösche den alten Schlüssel beim Anbieter.
5. Prüf die Nutzungsprotokolle des Anbieters auf Aktivitäten, die du nicht erkennst.

Die Chat-Nachricht oder den Git-Commit zu löschen reicht nicht. Der Git-Verlauf behält alte Versionen, und alles Öffentliche wurde möglicherweise schon kopiert.

Häufige Fehler

• Einen Schlüssel in den Prompt einfügen. Er steht jetzt im Chatverlauf. Nutze stattdessen ein Formular für Geheimnisse.
• Ein öffentliches Präfix bei einer geheimen Variablen. VITE_OPENAI_API_KEY liefert den Schlüssel an jeden Besucher aus.
• Eine .env-Datei committen. Stell sicher, dass sie in .gitignore steht, bevor du zum ersten Mal pushst.
• Ein Schlüssel für alles. Verwende getrennte Schlüssel für Test und Live und für jede App.
• Kein Ausgabelimit. Ein geleakter oder missbrauchter Schlüssel ohne Obergrenze kann eine hohe Rechnung verursachen, bevor du es bemerkst.
• Verstecken statt rotieren. Sobald ein Schlüssel offengelegt war, hilft nur ein neuer.
• Schlüssel in Screenshots. Schneide Einstellungsseiten zu oder unkenntlich, bevor du sie für Hilfe teilst.

Checkliste

• Jeder Schlüssel ist als Geheimnis oder Umgebungsvariable gespeichert, nicht im Code.
• Keine .env-Datei und kein Schlüssel ist in Git committet.
• Geheime Schlüssel werden nur im serverseitigen Code genutzt.
• Keine geheime Variable hat ein öffentliches Präfix wie VITE_ oder NEXT_PUBLIC_.
• Ich habe das JavaScript der Live-Seite nach dem Präfix jedes Schlüssels durchsucht und nichts gefunden.
• Schlüssel sind eingeschränkt, wo der Anbieter es erlaubt.
• Test- und Live-Schlüssel sind getrennt.
• Kostenpflichtige Funktionen verlangen Anmeldung und haben Limits pro Nutzer.
• Jeder kostenpflichtige Anbieter hat eine Ausgabenobergrenze oder Warnung.
• Ich weiß, wie ich jeden Schlüssel rotiere, und jeder einmal offengelegte Schlüssel wurde rotiert.

Schlüssel sicher halten auf Mythex

Mythex hält Schlüssel auf zwei Wegen aus deinem Code und Chat heraus:

• Karte zum Anfordern von Geheimnissen. Braucht der Agent einen Schlüssel, zeigt er im Chat eine Karte, auf der du den Wert in Formularfelder eingibst, nicht ins Nachrichtenfeld. Er wird als Projektgeheimnis gespeichert. Siehe Geheimnisse im Chat.
• Projekteinstellungen → Geheimnisse oder /secrets im Chat, um Schlüssel selbst hinzuzufügen oder zu ändern. Siehe Umgebungsvariablen und Geheimnisse.

Nach einer Änderung eines Geheimnisses für eine veröffentlichte App veröffentlichst du erneut, damit die Live-App es übernimmt. Exportierte Projekte enthalten keine Geheimnisse, trag sie dort wieder ein, wo du den Code als Nächstes ausführst. Taucht ein Schlüssel jemals im Chat auf, rotiere ihn beim Anbieter.

Für den restlichen Sicherheitscheck vor dem Start arbeite die Sicherheits-Checkliste für KI-gebaute Apps durch. Wenn du KI-Funktionen ergänzt, behandelt So nutzt du LLM-APIs Schlüssel und Kosten ausführlicher.

Fragen