Scanner für geleakte Secrets
Ein Scanner für geleakte Secrets prüft, ob Dateien und Zugangsdaten, die nie öffentlich sein dürften, von jedermann von Ihrer Website abgerufen werden können: eine .env-Datei mit Datenbankpasswörtern, ein .git-Ordner, der Ihre gesamte Quellhistorie ausliefert, ein im Webroot vergessenes Backup-Archiv oder ein echter API-Schlüssel in einem JavaScript-Bundle. Geben Sie eine URL ein, und dieser Scanner fragt die bekannten Offenlegungspfade ab, verifiziert den Inhalt jeder Antwort und durchsucht die Seite und ihre Skripte nach bekannten Secret-Mustern — angezeigt werden nur maskierte Werte, nie das Secret selbst. Der Begleitartikel Offenliegende .env-Dateien und geleakte Schlüssel erklärt, wie solche Offenlegungen entstehen und warum das Löschen der Datei allein nie genügt. Kombinieren Sie ihn mit dem Security-Headers-Check für Antwort-Härtung und dem Third-Party-Script-Audit für Skripte, die Sie von anderen laden.
Zuletzt aktualisiert:
Soll das laufend überwacht werden? Kostenlos mit myeventwatch überwachen — Ablauf- und Ausfallwarnungen, keine Karte nötig.
Was als offenliegend zählt — und was nicht
Der Scanner fragt eine veröffentlichte Liste bekannter Pfade — /.env und seine üblichen Varianten, /.git/HEAD und /.git/config, Konfigurationsdateien, Backup-Archive und Schlüsseldateien — mit schlichten öffentlichen GET-Anfragen ab, genau den Anfragen, die auch ein Angreifer, eine Suchmaschine oder ein neugieriger Besucher stellen könnte. Ein Pfad zählt nur dann als offenliegend, wenn der Antwortinhalt zu dem passt, wie diese Datei tatsächlich aussehen muss: Eine Env-Datei muss sich als Schlüssel-Wert-Zeilen parsen lassen, ein Git-HEAD muss wie eine Git-Referenz aussehen. Viele Server antworten auf jeden Pfad mit 200 — Single-Page-App-Fallbacks, eigene Fehlerseiten, Catch-all-Rewrites — und ein 200 mit dem HTML Ihrer Startseite ist kein Leak. Solche Pfade werden im Ergebnis getrennt als geantwortet, aber unbestätigt gelistet, damit Sie selbst urteilen können; dieses Tool nennt ein unbestätigtes 200 nie einen Leak, und kein Scanner, den Sie nutzen, sollte das tun.
Neben den Dateiproben holt der Scanner die Seite selbst und bis zu etwa fünfzehn ihrer JavaScript-Bundles und durchsucht sie nach bekannten Secret-Formen: Cloud-Zugriffsschlüssel-IDs, Private-Key-Header, generische API-Schlüssel- und Token-Zuweisungen, Datenbank-Verbindungszeichenfolgen und ähnliche Signale mit hoher Trefferqualität. Clientseitiger Code ist per Definition öffentlich — alles, was an einen Browser ausgeliefert wird, kann jeder Besucher lesen —, sodass ein echtes Zugangsdatenpaar in einem Bundle offenliegt, selbst wenn keine Datei falsch konfiguriert war. Funde werden nach Typ, Quelldatei und Anzahl der Vorkommen gemeldet, mit auf höchstens die ersten vier Zeichen maskiertem Wert: genug, damit Sie erkennen, welcher Schlüssel es ist, nie genug, damit ein Leser des Berichts ihn verwenden könnte. Das vollständige Secret wird in diesen Bericht nie geholt, gespeichert oder angezeigt.
Grenzen, klar benannt
Dies ist eine öffentliche, nur lesende Abfrage bekannter Pfade, und ihre Grenzen sind Teil des Ergebnisses. Sie fragt nur die Pfade der veröffentlichten Liste ab — ein Secret in einer ungewöhnlich benannten Datei wird nicht gefunden. Sie durchsucht die Landingpage und rund fünfzehn Skript-Bundles, nicht jedes Asset einer großen Website, und sie meldet sich nicht an, crawlt nicht hinter einer Authentifizierung, errät keine Dateinamen und testet nichts, was nicht ohnehin per unauthentifiziertem GET erreichbar ist. Scans sind auf 5 pro Stunde und Besucher begrenzt, Ergebnisse werden 10 Minuten zwischengespeichert, sodass ein erneuter Scan in diesem Fenster das zwischengespeicherte Urteil zeigen kann. Ein Scan läuft zudem mit einem Zeitbudget: Erschöpft ein langsames Ziel es, wird das Ergebnis als teilweise markiert und sagt das auch — behandeln Sie ein teilweises sauberes Ergebnis als „nicht vollständig geprüft“, nicht als „sauber“.
Findet der Scan etwas, zählt die Reihenfolge der Arbeit mehr als die Geschwindigkeit des Löschens. Rotieren Sie zuerst die Zugangsdaten — widerrufen Sie den offenliegenden Schlüssel und stellen Sie einen neuen aus —, denn Kopien können bereits in Caches, Archiven und fremden Händen existieren; das Löschen der Datei stoppt neue Downloads, tut aber nichts für einen Schlüssel, der bereits draußen ist. Entfernen oder blockieren Sie dann die Datei am Server, leeren Sie CDN- und Proxy-Caches, die eine Kopie halten könnten, und prüfen Sie Ihre Zugriffsprotokolle auf frühere Abrufe desselben Pfades. Der Begleitartikel Offenliegende .env-Dateien und geleakte Schlüssel führt der Reihe nach durch das Vorgehen der Angreifer in der ersten Stunde und die vollständige Wiederherstellungsfolge.
Benachbarte Checks vervollständigen das Bild: Das Third-Party-Script-Audit deckt die externen Skripte ab, die Ihre Seiten laden — ein anderes Lieferkettenrisiko als Ihre eigenen geleakten Dateien —, und der Security-Headers-Check bewertet die Browser-Schutzmechanismen Ihrer Antworten. Eine Anmerkung zur Methode: Ein sauberes Ergebnis bedeutet, dass keiner der abgefragten Pfade mit passendem Inhalt antwortete und kein bekanntes Secret-Muster in den durchsuchten Dateien auftauchte — zum Scanzeitpunkt und aus der Netzposition des Checkers. Es ist ein Nachweis über diese Pfade und Dateien, keine Garantie für den ganzen Server — halten Sie die Dateien von vornherein aus dem Webroot und scannen Sie nach jeder Deployment-Änderung erneut, die berührt, was Ihr Server veröffentlicht.
Die Abfrageliste, veröffentlicht
| /.env und Varianten | Umgebungsdateien (.env, .env.local, .env.production und ähnliche) mit Datenbankpasswörtern, Mail-Zugangsdaten und API-Schlüsseln. Nur bestätigt, wenn der Body sich als Schlüssel-Wert-Zeilen parsen lässt. |
| /.git/HEAD und /.git/config | Ein ausgelieferter .git-Ordner offenbart das Repository: HEAD beweist die Struktur, config nennt oft das Remote. Mit beidem lässt sich die volle Quellhistorie meist rekonstruieren. |
| Konfigurationsdateien | Bekannte Konfigurationspfade (zum Beispiel wp-config-Backups, config.php-Kopien und Framework-Konfigurationsdateien), die Zugangsdaten im Klartext tragen. |
| Backup- und Archivdateien | Datenbank-Dumps, .zip- / .tar.gz-Website-Archive und Editor-Backup-Kopien im Webroot — oft eine vollständige Kopie der Website, Zugangsdaten inklusive. |
| Schlüssel- und Zertifikatsdateien | Dateien in Private-Key-Form (.pem, .key, Namen im id_rsa-Stil), die nie per Web erreichbar sein dürfen; ein ausgelieferter privater Schlüssel ist für sich ein kritischer Fund. |
| JavaScript-Bundles | Die Seite plus bis zu etwa 15 Skript-Bundles, durchsucht nach Cloud-Schlüssel-IDs, Private-Key-Headern, Token-Zuweisungen und Verbindungszeichenfolgen. Werte werden auf höchstens vier führende Zeichen maskiert. |
| Bestätigungsregel | Eine Abfrage zählt nur als offenliegend, wenn der Antwortinhalt zur erwarteten Dateiform passt. Ein bloßes 200 wird als geantwortet-unbestätigt gelistet und nie als Leak gemeldet. |
| Budget und Caching | Nur öffentliche GET-Abfragen, nur lesend, 5 Scans pro Stunde und Besucher, Ergebnisse 10 Minuten zwischengespeichert. Ein Scan, der sein Zeitbudget erschöpft, wird als teilweise markiert. |
Häufige Fragen
Der Scan sagt, ein Pfad habe „geantwortet, aber unbestätigt“. Ist das ein Leak?
Nach dieser Evidenz: nein. Es bedeutet, dass der Pfad mit HTTP 200 antwortete, der Inhalt aber nicht zur Form der abgefragten Datei passte — die übliche Ursache ist eine Catch-all-Route oder Fallback-Seite, die jede URL mit Ihrer Startseite oder App-Shell beantwortet. Öffnen Sie den Pfad selbst in einem privaten Fenster und sehen Sie, was wirklich zurückkommt: Sehen Sie den echten Dateiinhalt, behandeln Sie ihn als offenliegend; sehen Sie Ihre normale Website, ist es der Fallback.
Der Scanner hat einen meiner Schlüssel gefunden. Was tue ich zuerst?
Rotieren Sie ihn — widerrufen Sie die offenliegenden Zugangsdaten und stellen Sie Ersatz aus — vor allem anderen. Kopien einer öffentlichen Datei entkommen schnell in Caches, Archive und Scanner-Datenbanken, sodass das Löschen der Datei einen Schlüssel nicht „ent-leakt“. Entfernen oder blockieren Sie dann die Datei, leeren Sie CDN- und Proxy-Caches, prüfen Sie die Zugriffsprotokolle für den Pfad und kontrollieren Sie, wo dieselben Zugangsdaten sonst noch verwendet wurden.
Speichert oder zeigt der Scanner die vollständigen gefundenen Secrets?
Nein. Der Checker meldet Secret-Typ, die Funddatei und eine Anzahl der Vorkommen, mit auf höchstens die ersten vier Zeichen maskiertem Wert — genug, um zu erkennen, welche Zugangsdaten es sind, nie genug, um sie zu benutzen. Der Bericht enthält absichtlich nichts Stehlenswertes: Ein Leak-Bericht sollte kein zweiter Leak werden.
Kann er meine Staging-Website oder eine Seite hinter einem Login scannen?
Nein. Der Scanner stellt nur unauthentifizierte öffentliche GET-Anfragen, sodass alles hinter einem Login, einem VPN oder einer IP-Freigabeliste außer Reichweite ist — absichtlich, denn die Frage, die er beantwortet, lautet, was ein Fremder im Internet abrufen kann. Blockierte Ziele, einschließlich der Infrastrukturadressen dieser Website selbst, werden rundheraus abgelehnt.
Warum ist mein Ergebnis zwischengespeichert oder teilweise?
Ergebnisse werden 10 Minuten zwischengespeichert, damit Wiederholungsprüfungen billig bleiben und der Scanner ein höflicher Gast auf dem Zielserver ist; das Ergebnis vermerkt, wenn es aus dem Cache stammt. Ein teilweises Ergebnis bedeutet, dass der Scan sein Zeitbudget — meist ein langsames Ziel oder viele große Bundles — erreichte, bevor jede Abfrage fertig war; das Banner sagt das, und ein teilweises sauberes Ergebnis sollte erneut laufen, statt ihm als vollständig sauber zu vertrauen.