Was tun, wenn API-Keys in einem Repository landen

Jan 29, 2026 · 4 min read

Was tun, wenn API-Keys in einem Repository landen

Sie haben Code zu GitHub gepusht und Sekunden später festgestellt, dass Ihr API-Key mitgegangen ist. Vielleicht hat GitHub Ihnen eine Warnung geschickt. Vielleicht hat GitGuardian Ihnen eine E-Mail gesendet. So oder so haben Sie es nun mit exponierten Secrets in Frontend-Anwendungen zu tun – und die Zeit läuft.

Hier ist der entscheidende Punkt, den die meisten Entwickler falsch verstehen: Das Entfernen des Keys aus Ihrem letzten Commit behebt das Problem nicht. Die Git-Historie bewahrt alles auf. Forks könnten bereits existieren. Automatisierte Bots scannen öffentliche Repositories innerhalb von Sekunden nach einem Push.

Dieser Artikel behandelt genau, was zu tun ist, wenn API-Keys auf GitHub geleakt werden, wie man zwischen wirklich sensiblen Secrets und öffentlichen Client-Keys unterscheidet und wie man verhindert, dass dies erneut passiert.

Wichtigste Erkenntnisse

Widerrufen und rotieren Sie exponierte Secrets sofort – die Bereinigung der Git-Historie ist zweitrangig, da der Key bereits kompromittiert ist.
Unterscheiden Sie zwischen öffentlichen Client-Keys (für die Browser-Nutzung konzipiert) und echten Secrets (privilegierte Zugangsdaten, die dringendes Handeln erfordern).
Die Git-Historie bewahrt alles auf, sodass das Löschen eines Commits das Secret nicht aus Forks, Caches oder bestehenden Klonen entfernt.
Aktivieren Sie GitHubs Push-Protection, um Commits mit Secrets zu blockieren, bevor sie Ihr Repository erreichen.
Speichern Sie niemals privilegierte Keys in Frontend-Code – verwenden Sie stattdessen serverseitige API-Routen oder Backend-Proxys.

Verstehen Sie zunächst, was Sie tatsächlich exponiert haben

Nicht alle Keys bergen das gleiche Risiko. Bevor Sie in Panik geraten, identifizieren Sie, welche Art von Zugangsdaten geleakt wurde.

Öffentliche Client-Keys sind dafür konzipiert, sichtbar zu sein. Google Maps API-Keys, die auf bestimmte Domains beschränkt sind, Analytics-Tokens oder Keys, die explizit für die clientseitige Verwendung gekennzeichnet sind (wie NEXT_PUBLIC_ in Next.js oder VITE_ in Vite), sind dafür gedacht, in Browser-Bundles ausgeliefert zu werden. Diese sollten dennoch Nutzungsbeschränkungen haben, aber eine Exponierung ist nicht katastrophal.

Echte Secrets gewähren privilegierten Zugriff: Stripe Secret Keys, AWS-Zugangsdaten, Datenbank-Verbindungsstrings oder jeder Key, der sensible Daten lesen/schreiben oder Kosten verursachen kann. Diese erfordern sofortiges Handeln.

Die Unterscheidung ist wichtig, weil Ihre Reaktion der Schwere entsprechen sollte.

Sofortmaßnahme: Zuerst widerrufen und rotieren

Wenn Sie ein echtes Secret geleakt haben, ist die Bereinigung der Historie zweitrangig. Ihre erste Priorität ist die Rotation kompromittierter API-Keys.

Schritt 1: Widerrufen Sie den exponierten Key sofort. Melden Sie sich im Dashboard Ihres API-Anbieters an und löschen oder deaktivieren Sie die kompromittierten Zugangsdaten. Warten Sie nicht, bis Sie die Git-Historie bereinigt haben – der Key ist bereits kompromittiert.

Schritt 2: Generieren Sie einen neuen Key mit minimalem Scope. Wenden Sie das Prinzip der geringsten Privilegien an. Beschränken Sie nach Möglichkeit nach IP, Domain oder bestimmten API-Endpunkten.

Schritt 3: Aktualisieren Sie Ihre Anwendung. Deployen Sie den neuen Key in Ihre Umgebungen, bevor Ihre Anwendung ausfällt.

Einige Cloud-Provider deaktivieren automatisch Zugangsdaten, die sie in öffentlichen Repositories erkennen. Google Cloud kann beispielsweise exponierte Service-Account-Keys standardmäßig automatisch deaktivieren. Andere, einschließlich AWS, benachrichtigen Sie in der Regel, widerrufen Keys jedoch nicht konsequent automatisch. Alle diese Anbieter nehmen am Secret-Scanning-Partnerprogramm von GitHub teil. Verlassen Sie sich nicht auf Automatisierung – handeln Sie trotzdem sofort.

Warum das Löschen des Commits nicht ausreicht

Git vergisst nie. Selbst wenn Sie das Secret aus Ihrem aktuellen Branch entfernen, lebt es weiter in:

Früheren Commits, die über git log zugänglich sind
Forks, die vor Ihrer Korrektur erstellt wurden
Bestehenden Klonen, die von anderen Benutzern oder Bots gepullt wurden
Allen Mirrors, die vor der Entfernung erstellt wurden

Deshalb kommt der Widerruf zuerst. Die Bereinigung der Historie ist Eindämmung, nicht Behebung.

Wenn Sie die Historie bereinigen müssen, können Tools wie git filter-repo oder BFG Repo-Cleaner helfen. Aber verstehen Sie: Wenn Ihr Repository für eine beliebige Zeitspanne öffentlich war, gehen Sie davon aus, dass das Secret erfasst wurde.

GitHub Secret Scanning und Push Protection

GitHub bietet erstklassigen Schutz gegen genau dieses Problem. Secret Scanning und Push Protection sind für alle öffentlichen Repositories und für private Repositories über GitHub Secret Protection (auch in GitHub Advanced Security enthalten) verfügbar.

Secret Scanning erkennt bekannte Zugangsdatenmuster in Ihrem Repository und benachrichtigt automatisch Sie und/oder den Anbieter.

Push Protection geht weiter – es blockiert Commits mit erkannten Secrets, bevor sie das Repository erreichen. Dies ist der effektivste verfügbare Präventionsmechanismus.

Aktivieren Sie beide in Ihren Repository-Einstellungen unter Settings → Code security and analysis oder lesen Sie die offizielle Dokumentation zu GitHub Secret Protection.

Die Frontend-Umgebungsvariablen-Falle

Hier ist ein Fehler, der viele React-, Vue- und Next.js-Entwickler erwischt: Umgebungsvariablen mit Präfix für die Client-Nutzung sind keine Secrets.

Variablen wie REACT_APP_*, NEXT_PUBLIC_* oder VITE_* werden direkt in Ihr JavaScript gebündelt. Jeder kann die DevTools öffnen und sie finden. Diese sind nicht verborgen – sie sind nur organisiert.

Wenn ein Key privilegierten Zugriff gewährt, kann er nicht im Frontend-Code leben. Punkt.

Präventionsstrategien für Frontend-Teams

Halten Sie privilegierte Keys serverseitig. Verwenden Sie API-Routen, Serverless-Funktionen oder einen Backend-Proxy. Ihr Frontend authentifiziert Benutzer; Ihr Backend hält die Secrets.

Aktivieren Sie Push Protection. Dies fängt Fehler ab, bevor sie zu Vorfällen werden.

Verwenden Sie Pre-Commit-Hooks. Tools wie gitleaks oder detect-secrets scannen gestage Änderungen lokal.

Fügen Sie CI-Scanning hinzu. Führen Sie Secret-Erkennung in Ihrer Pipeline als Sicherheitsnetz aus.

Beschränken Sie Keys aggressiv. Selbst öffentliche Client-Keys sollten nach Domain, IP oder API-Scope eingeschränkt werden.

Fazit

Wenn API-Keys leaken, zählt Geschwindigkeit mehr als Perfektion. Widerrufen Sie zuerst, rotieren Sie sofort, und bereinigen Sie dann die Historie als sekundären Schritt. Verwechseln Sie nicht öffentliche Client-Keys mit echten Secrets, und vertrauen Sie niemals darauf, dass Umgebungsvariablen irgendetwas in Frontend-Builds verbergen.

Aktivieren Sie noch heute GitHubs Push Protection. Es ist der einfachste Weg sicherzustellen, dass dieses Problem nie wieder auftritt.

FAQs

Widerrufen oder deaktivieren Sie den exponierten Key sofort über das Dashboard Ihres API-Anbieters. Warten Sie nicht, bis Sie zuerst Ihre Git-Historie bereinigt haben. Der Key ist bereits kompromittiert in dem Moment, in dem er in ein öffentliches Repository gepusht wurde, und automatisierte Bots können ihn innerhalb von Sekunden erfassen. Generieren Sie nach dem Widerruf einen neuen Key und aktualisieren Sie Ihre Anwendung.

Nein. Git bewahrt die gesamte Historie auf, sodass das Secret in früheren Commits, Forks, bestehenden Klonen und allen Kopien, die vor Ihrer Korrektur erstellt wurden, zugänglich bleibt. Das Löschen oder Ändern des Commits entfernt es nur von der aktuellen Branch-Spitze. Sie müssen den Key unabhängig von jeglicher Historie-Bereinigung, die Sie danach durchführen, widerrufen.

Nein. Diese Umgebungsvariablen mit Präfix werden direkt in Ihr Frontend-JavaScript gebündelt und sind für jeden sichtbar, der die Browser-DevTools öffnet. Sie sind für öffentliche Konfigurationswerte gedacht, nicht für Secrets. Jeder Key, der privilegierten Zugriff gewährt, muss serverseitig gespeichert und über API-Routen oder Backend-Proxys aufgerufen werden.

Aktivieren Sie GitHub Push Protection, um Commits mit erkannten Secrets zu blockieren, bevor sie Ihr Repository erreichen. Verwenden Sie Pre-Commit-Hooks mit Tools wie gitleaks oder detect-secrets, um Änderungen lokal zu scannen. Fügen Sie Secret-Erkennung zu Ihrer CI-Pipeline als zusätzliches Sicherheitsnetz hinzu. Diese Ebenen arbeiten zusammen, um Fehler frühzeitig abzufangen.

Understand every bug

Uncover frustrations, understand bugs and fix slowdowns like never before with OpenReplay — the open-source session replay tool for developers. Self-host it in minutes, and have complete control over your customer data. Check our GitHub repo and join the thousands of developers in our community.