Für jeden Schlüssel einen nachvollziehbaren Zweck festhalten
Ein API-Key hat kein überall gleiches Berechtigungsmodell. Klären Sie beim Anbieter oder in Ihrer eigenen Implementierung, welche Identität er repräsentiert, welche Operationen er erlaubt, ob er abläuft und wie er widerrufen wird. Die Zeichenfolge allein beantwortet das nicht.
Führen Sie ein Inventar ohne Geheimniswerte: Schlüsselkennung, Anwendung, Umgebung, Verantwortlicher, erlaubte Ressourcen, letzter geplanter Wechsel und Sperrweg. Eine nicht geheime Kennung oder ein ausreichend begrenzter Fingerabdruck dient der Zuordnung. Der vollständige Schlüssel muss dafür nicht in einer Tabelle stehen.
Trennen Sie mindestens Entwicklung und Produktion sowie Integrationen mit unterschiedlichen Aufgaben. So muss ein Testzugang keine Kundendaten lesen und ein Exportdienst keine Benutzer verwalten. Eine Schlüsselbeschränkung ist nur wirksam, wenn der Empfänger sie bei der Nutzung durchsetzt. Die OWASP-Empfehlungen zum Geheimnislebenszyklus verbinden Erstellung, begrenzte Rechte, Wechsel, Widerruf und Ablauf.
Geheimnisse dort bereitstellen, wo sie gebraucht werden
Bei einer ausgehenden Integration benötigt der aufrufende Prozess den verwendbaren Schlüssel. Stellen Sie ihn zur Laufzeit über die Geheimnisverwaltung Ihrer Umgebung bereit. Gewähren Sie nur den benötigten Dienstidentitäten Zugriff. Auch Sicherungen, administrative Exporte und der Wiederherstellungsweg gehören in diese Betrachtung.
Eine Umgebungsvariable kann helfen, Werte aus dem Quellcode herauszuhalten. Sie ist jedoch kein eigener Tresor: Startskripte, Diagnoseausgaben, Prozessrechte, Containerkonfiguration und Fehlerberichte können sie offenlegen. Entscheidend ist der gesamte Bereitstellungsweg. Vermeiden Sie in Anleitungen und Runbooks Befehle, die vollständige Schlüssel zum Bildschirm oder Log ausgeben.
Wenn Sie selbst Schlüssel ausgeben und eingehende Requests prüfen, ist die Aufgabe anders. Der Server kann je nach Entwurf einen geeigneten nicht umkehrbaren Prüfwert statt des vollständigen geheimen Wertes speichern. Dieses Muster lässt sich nicht auf einen Client übertragen, der den Schlüssel an eine fremde API senden muss. Konstruktion, sichere Zufallserzeugung, Vergleich und Sperrprüfung sollten einer geeigneten vorhandenen Komponente folgen; ein selbst erfundenes Passwortschema ist keine Voraussetzung.
Die Google-Cloud-Empfehlungen sind ein konkretes Anbieterbeispiel für eingeschränkte Schlüssel, Vermeidung von Clientoffenlegung und sicheren Wechsel. Einzelne dort verfügbare Einschränkungen sind keine allgemeine Eigenschaft anderer APIs.
Den gesamten Requestweg betrachten
Übertragen Sie den Schlüssel nur über einen dafür vorgesehenen geschützten Kanal. Wenn der Dienst einen Header für geheime Schlüssel vorsieht, nutzen Sie ihn statt einer URL mit Queryparameter. URLs landen häufig in Zugriffsprotokollen, Verlauf, Telemetrie oder weitergegebenen Fehlerberichten. Auch Header sind kein automatisch geheimer Speicherort: Redigieren Sie sie an Gateway, Proxy, Anwendung und Observability-System.
Eine IP-Einschränkung kann ein zusätzlicher Schutz für bekannte Serverausgänge sein. Sie ersetzt nicht die Prüfung des Schlüssels und seiner Rechte. Eine Browser-Referrerregel macht einen eingebetteten geheimen Schlüssel ebenfalls nicht vertraulich. Prüfen Sie die jeweilige Funktion anhand ihrer dokumentierten Schutzgrenze.
Ein serverseitiger Vermittler schützt einen geheimen Anbieterschlüssel nur dann sinnvoll, wenn sein eigener Zugang kontrolliert ist. Ein anonym erreichbarer Proxy, der mit Ihren vollen Rechten beliebige kostenpflichtige Aufträge weiterleitet, verschiebt das Problem. Er benötigt eigene Authentifizierung, fachliche Grenzen und gegebenenfalls Ressourcenbudgets.
Einen geplanten Schlüsselwechsel kontrolliert durchführen
Für die folgende Abfolge wird vorausgesetzt, dass der Dienst zwei zeitweise gültige Schlüssel unterstützt. Falls das nicht möglich ist, brauchen Sie einen dokumentierten Umschaltzeitpunkt mit geeignetem Unterbrechungsplan.
- Verbraucher und Rechte prüfen. Erfassen Sie Webprozesse, Hintergrundjobs, Warteschlangenarbeiter und selten laufende Aufgaben. Der neue Schlüssel bekommt die beabsichtigten Rechte, nicht vorsorglich mehr.
- Ersatz geschützt bereitstellen. Legen Sie eine neue Version im vorgesehenen Geheimnissystem an. Halten Sie den alten Wert aus Tickets und Deploymentausgaben heraus.
- Begrenzte Verbraucher umstellen. Prüfen Sie einen risikoarmen regulären Zugriff und dessen erwartetes Ergebnis. Ein bloßes HTTP
200reicht nicht, wenn der Dienst dabei eine andere Ressource liefert. - Restliche Verbraucher wechseln. Beobachten Sie Fehler und Nutzung nach nicht geheimer Schlüsselkennung. Berücksichtigen Sie langlebige Prozesse und zwischengespeicherte Konfiguration.
- Alten Schlüssel widerrufen. Belegen Sie anschließend, dass er keinen Zugriff mehr gewährt und der neue Zugang weiterhin die nötige Aufgabe erfüllt. Nutzen Sie dafür einen kontrollierten, nicht verändernden eigenen Prüfweg.
Eine Rotation ist erst abgeschlossen, wenn der alte Zugang unwirksam ist. Das Löschen der Zeichenfolge aus dem aktuellen Deployment genügt nicht. Unterbrechen Sie bei unerwarteten Fehlern den weiteren Rollout und klären Sie Rechte, Zielumgebung und geladene Version. Bei einem rein geplanten Wechsel kann eine noch sichere alte Konfiguration kurzzeitig als Rückweg dienen; dokumentieren Sie die verlängerte Gültigkeit.
Bei einem vermuteten Leck gilt eine andere Reihenfolge
Ist ein geheimer Schlüssel öffentlich geworden oder möglicherweise entwendet, behandeln Sie ihn als kompromittiert. Sperren Sie ihn über den vorgesehenen Weg und stellen Sie einen neuen Zugang aus einer sauberen Umgebung bereit. Je nach Auswirkung kann das eine bewusste Unterbrechung erfordern. Warten Sie nicht auf den nächsten regulären Rotationstermin.
Sichern Sie die zur Klärung nötigen Ereignisdaten mit begrenztem Zugriff: wann die Offenlegung begann, welche Schlüsselkennung betroffen ist und welche Nutzung sichtbar wurde. Kopieren Sie den Geheimniswert dafür nicht zusätzlich in Berichte. Untersuchen Sie betroffene Ressourcen, ungewöhnliche Aktionen und mögliche Folgeschlüssel. Die Reichweite folgt den tatsächlichen Rechten, nicht dem Namen der Anwendung.
Entfernen Sie danach die Offenlegungsquelle und stellen Sie deren Verhalten ab. Ein gelöschter Git-Commit, eine bereinigte Logdatei oder ein geschlossener Chat widerruft den Zugang nicht und holt bestehende Kopien nicht zurück. Die OWASP Secrets Management-Empfehlungen zur Reaktion behandeln Widerruf und Ursachenbehebung als zusammengehörige Aufgaben. Reaktivieren Sie einen kompromittierten Schlüssel auch zur Rücknahme einer Änderung nicht.
Woran Sie eine tragfähige Verwaltung erkennen
Üben Sie den Wechsel zunächst mit rein synthetischen oder eigenen Testzugängen. Prüfen Sie erlaubte und unerlaubte Operationen, Ablauf und Sperrung sowie einen vergessenen Hintergrundprozess. Das Ergebnis sollte erkennen lassen, welcher Zugang zu welchem Zeitpunkt verwendet wurde, ohne dessen Wert offenzulegen.
Kontrollieren Sie außerdem, ob Browserassets, Quellverwaltung, Logs und Diagnosewege Geheimnisse enthalten können. Ein Suchlauf ohne Treffer beweist keine vollständige Geheimnisfreiheit; verschiedene Systeme brauchen unterschiedliche Kontrollen. Benennen Sie deshalb den tatsächlich geprüften Bereich.
Der API Security Check liest keine Geheimnisspeicher und führt keinen Schlüsselwechsel oder Zugangstest aus. Wenn die eigentliche Frage Benutzerfreigaben und deren Widerruf betrifft, prüfen Sie stattdessen die passende Authentifizierungsarchitektur und OAuth/OIDC. Quellenstand: 27. September 2026.
Quellen und Stand
Quellenstand: 27. September 2026. Die Links stehen zusätzlich bei den jeweils begründeten Aussagen.