Exponierte .git- und .env-Dateien auf Websites finden

Der häufigste Totalschaden ist ein vergessenes Artefakt

In der aktualisierten Risikoliste der OWASP ist Security Misconfiguration von Platz fünf auf Platz zwei aufgestiegen (OWASP Top 10:2025). Die Datenbasis dahinter ist deutlich: eine durchschnittliche Auftretensrate von 3,00 Prozent bei einer maximalen Rate von 27,70 Prozent, 719.084 erfasste Vorkommen und 1.375 zugeordnete CVEs über 16 gebündelte Schwachstellenklassen (OWASP Top 10:2025, A02 Security Misconfiguration). Bemerkenswerter als die Rangfolge ist der Befund dahinter: In der ausgewerteten Datenbasis wies jede getestete Anwendung irgendeine Form von Fehlkonfiguration auf (OWASP Top 10:2025).

Ein exponiertes .git-Verzeichnis ist der Prototyp dieser Kategorie. Es ist keine Schwachstelle im Sinne eines Programmierfehlers, kein Pufferüberlauf, keine Injection. Es ist eine Datei, die dort liegt, wo sie niemand vermutet hat - und die der Webserver pflichtbewusst ausliefert, weil ihm niemand etwas anderes vorgegeben hat. Genau deshalb taucht sie in keinem Schwachstellen-Feed auf. Wer seine Sicherheitsarbeit auf CVE-Meldungen stützt, wird von diesem Risiko strukturell nicht erreicht.

Das BSI zählt für den Berichtszeitraum Juli 2024 bis Juni 2025 durchschnittlich 119 neue Schwachstellen pro Tag, ein Zuwachs von rund 24 Prozent gegenüber dem Vorjahresbericht (BSI, Die Lage der IT-Sicherheit in Deutschland 2025). Im selben Zeitraum registrierte das BSI 950 Ransomware-Fälle, von denen rund 80 Prozent kleine und mittlere Unternehmen trafen (BSI, Die Lage der IT-Sicherheit in Deutschland 2025). Diese Zahlen beschreiben den Druck - aber sie beschreiben nicht den Einstiegsweg. Der ist in vielen Fällen banaler: ein Zugangsdatensatz, der irgendwo abrufbar war.

Die Ökonomie auf der Angreiferseite ist entsprechend einfach. Es braucht kein Exploit-Wissen, nur eine Liste von Domains und einen HTTP-Client. Am 20. und 21. April 2025 beobachtete GreyNoise rund 4.800 einzelne IP-Adressen täglich, die gezielt nach /.git/config suchten - der größte Ausschlag seit September 2024, während die drei vorangegangenen Wellen jeweils bei etwa 3.000 IP-Adressen lagen (GreyNoise). 95 Prozent aller in einem 90-Tage-Fenster beobachteten IP-Adressen dieser Kategorie wurden als bösartig eingestuft (GreyNoise). Deutschland lag mit 4.138 beobachteten IP-Adressen auf Platz drei der Zielregionen, hinter Singapur und den USA (GreyNoise).

Die Fundliste: was auf Websites tatsächlich erreichbar ist

Die folgende Liste ist keine theoretische Sammlung. Sie beschreibt die Pfade, die in externen Prüfungen von Firmenwebsites regelmäßig mit HTTP 200 antworten - meist auf Systemen, die ansonsten sauber gepflegt sind (Projekterfahrung). Der gemeinsame Nenner: Alle diese Dateien entstehen im Entwicklungs- oder Deployment-Prozess und haben im ausgelieferten Verzeichnis nichts zu suchen.

Diese Aufzählung deckt sich mit dem Prüfpunkt, den der OWASP Web Security Testing Guide unter WSTG-CONF-04 beschreibt: die Suche nach alten, gesicherten und nicht verlinkten Dateien mit sensiblen Inhalten (OWASP Web Security Testing Guide). Der Leitfaden nennt drei Wirkungen: Konfigurationsdateien mit Datenbank-Zugangsdaten und internen Pfaden, nicht verlinkte Verwaltungsseiten mit mächtiger Funktionalität und alte Dateiversionen, in denen bereits behobene Fehler weiterhin ausnutzbar bleiben (OWASP Web Security Testing Guide).

Backup-Archive können Kopien aller Dateien innerhalb - oder sogar außerhalb - des Webroots enthalten. Das erlaubt es Angreifern, die gesamte Anwendung schnell zu erfassen, einschließlich nicht verlinkter Seiten, Quellcode und Include-Dateien.

— OWASP Web Security Testing Guide, WSTG-CONF-04 (sinngemäße Übersetzung)

Warum eine 403-Antwort auf /.git/ gar nichts beweist

Der häufigste Trugschluss läuft so: Jemand ruft https://ihre-domain.de/.git/ im Browser auf, sieht eine 403-Seite und hält das Thema für erledigt. Diese Prüfung ist wertlos, weil sie die falsche Frage stellt. Ein Git-Repository wird nicht über das Verzeichnis gelesen, sondern über einzelne, namentlich bekannte Dateien darin.

Es gibt mindestens vier Gründe, warum ein 403 auf das Verzeichnis mit einem 200 auf die Dateien darunter zusammenfallen kann. Erstens: Viele Regelwerke sperren nur den exakten Verzeichnispfad (location = /.git/) statt aller Pfade, die damit beginnen. Zweitens: Ein 403 entsteht auch dann, wenn lediglich das Directory-Listing deaktiviert ist - der Webserver sagt damit Ich zeige dir den Inhalt nicht, nicht Ich liefere hier nichts aus. Drittens: Die Regel liegt am CDN oder an der Web Application Firewall, während der Origin-Server ungeschützt bleibt und über eine zweite Adresse erreichbar ist. Viertens: Die Regel existiert für www.ihre-domain.de, aber nicht für die Apex-Domain, die Staging-Subdomain oder eine alte Domain, die noch auf denselben Docroot zeigt.

GET https://ihre-domain.de/.git/          -> 403  (Verzeichnis gesperrt)
GET https://ihre-domain.de/.git/HEAD      -> 200  "ref: refs/heads/main"
GET https://ihre-domain.de/.git/config    -> 200  [remote "origin"] url=https://...
GET https://ihre-domain.de/.git/index     -> 200  DIRC ... (Dateiliste des Checkouts)

Bewertung: Das Repository ist vollständig lesbar.
Die 403-Antwort auf das Verzeichnis hat den Zugriff nicht verhindert -
sie hat nur das Directory-Listing unterbunden.

Die Konsequenz für die eigene Prüfroutine ist eindeutig: Nicht das Verzeichnis abfragen, sondern konkrete Dateien - und nicht nur den Statuscode auswerten, sondern den Inhalt. Ein Server, der auf jede Anfrage eine freundliche 200-Seite mit dem Text Seite nicht gefunden zurückgibt, macht die reine Statuscode-Prüfung wertlos.

• /.git/HEAD - antwortet mit ref: refs/heads/main oder einem Commit-Hash
• /.git/config - enthält die Remote-URL, oft mit Benutzername und Token
• /.git/index - beginnt mit der Signatur DIRC und listet alle Dateien des Checkouts
• /.git/logs/HEAD - Reflog mit Commit-Hashes, Autoren und Zeitstempeln
• /.git/packed-refs - Referenzliste aller Branches und Tags
• /.git/objects/info/packs - Verzeichnis der Packfiles für den Massendownload
• /.env und /.env.local - Inhalt auf KEY=VALUE-Muster prüfen, nicht nur auf Status 200

Vom Metadaten-Fetzen zum vollständigen Quellcode

Git ist ein inhaltsadressierter Objektspeicher. Jedes Objekt - Commit, Verzeichnisbaum, Dateiinhalt - liegt unter einem Pfad, der sich vollständig aus seinem SHA-Hash ergibt. Wer .git/HEAD lesen kann, kennt die aktuelle Referenz. Wer die Referenz auflöst, hat den Commit-Hash. Der Commit verweist auf einen Verzeichnisbaum, dieser auf weitere Bäume und Dateiinhalte. Jeder Schritt ist ein weiterer HTTP-Abruf unter einer berechenbaren Adresse. Ein Directory-Listing wird dafür an keiner Stelle gebraucht.

.git/index beschleunigt das Verfahren zusätzlich: Die Datei enthält die komplette Dateiliste des letzten Checkouts mit Pfaden und zugehörigen Objekt-Hashes. Sie ist damit ein fertiges Inhaltsverzeichnis - und macht aus der schrittweisen Rekonstruktion einen gezielten Abruf genau der Dateien, die interessant sind: Konfigurationen, Datenbankzugriffe, Zahlungsanbindungen, Deployment-Skripte.

Wie industriell dieses Vorgehen betrieben wird, zeigt eine dokumentierte Kampagne: Zwischen August und September 2024 durchsuchte eine Angreifergruppe Ziellisten mit über 500 Millionen IP-Adressen, 12.000 IP-Bereichen, 500.000 Domains und rund einer Million Cloud-Hostnamen systematisch nach dem Pfad /.git/config (Sysdig Threat Research Team, Operation EMERALDWHALE). Gefunden wurden mehr als 67.000 URLs mit exponierter Git-Konfiguration (Sysdig Threat Research Team). Daraus entstanden über 15.000 erbeutete Cloud-Zugangsdaten und Zugriff auf mehr als 10.000 private Repositories (Sysdig Threat Research Team). Von rund 6.000 stichprobenhaft geprüften Zugriffstoken waren etwa 2.000 noch gültig (Sysdig Threat Research Team).

Der Schaden endet nicht beim Quellcode. Aus einem gültigen Repository-Token folgt Schreibzugriff auf die Codebasis, aus Datenbankzugangsdaten folgt der Datenbestand, aus Mail-Zugangsdaten folgt Versand unter Ihrer Absenderdomain. Wer an dieser Stelle nur den Quellcode als Verlust betrachtet, unterschätzt den Vorgang erheblich. Dieselbe Kette macht auch Third-Party-Scripts zu einem Sicherheitsrisiko, sobald ein Angreifer Schreibrechte auf ausgelieferte Dateien erlangt.

Serverregeln für nginx und Apache

Die Serverregel ist die Notbremse, nicht die Lösung - aber sie wirkt sofort und sollte auf jedem System stehen. Zwei Details entscheiden über ihre Qualität: Sie muss auf Präfix-Basis greifen, also alle Pfade unterhalb des Verzeichnisses erfassen, und sie sollte 404 statt 403 zurückgeben. Ein 403 bestätigt einem Scanner, dass an dieser Stelle etwas liegt, das geschützt werden musste.

# nginx: Deployment-Artefakte nicht ausliefern (server-Block)

# Versionskontroll-Metadaten - Verzeichnis UND jede Datei darunter
location ~ /\.(git|svn|hg|bzr)(/|$) {
    return 404;
}

# Alle Punkt-Dateien, Ausnahme für ACME und security.txt
location ~ /\.(?!well-known/) {
    return 404;
}

# Backups, Dumps, Editor-Reste, Archive
location ~* \.(bak|old|orig|save|swp|swo|sql|dump|tar|tgz|zip|rar|7z)$ {
    return 404;
}

# Verzeichnislisten grundsätzlich deaktivieren
autoindex off;

Die zweite Regel im Beispiel sperrt alle Punkt-Dateien mit einer negativen Vorausschau auf .well-known/. Das ist wichtig, weil unter diesem Pfad legitime Inhalte liegen: die ACME-Bestätigung für Zertifikatsausstellung und die security.txt, die den Meldeweg für Schwachstellen dokumentiert. Wie Sie diesen Meldeweg korrekt aufsetzen, beschreibt der Beitrag zu security.txt und Vulnerability Disclosure.

# Apache 2.4: vHost-Konfiguration (bevorzugt) oder .htaccess

# Versionskontroll- und Umgebungsdateien: 404 statt 403 ausliefern
RedirectMatch 404 "/\.(git|svn|hg|bzr)(/|$)"
RedirectMatch 404 "/\.env"
RedirectMatch 404 "/\.DS_Store"

# Backups, Dumps und Editor-Reste
<FilesMatch "\.(bak|old|orig|save|swp|swo|sql|dump|tgz|zip)$">
    Require all denied
</FilesMatch>

# Verzeichnislisten aus
Options -Indexes

Wenn die Regeln stehen, gehört das Ergebnis in dieselbe Beobachtungsroutine wie Zertifikatslaufzeiten und Antwortzeiten. Der Security-Scan von XICTRAQ prüft die ausgelieferten Antworten von außen und meldet, wenn ein Pfad, der bisher mit 404 antwortete, plötzlich Inhalt zurückgibt. Ergänzend dazu behandelt der Beitrag zu HTTP-Security-Headern die zweite Hälfte der Auslieferungshärtung.

Deployment ohne Repository im Webroot

Nachhaltig gelöst ist das Problem erst, wenn das Repository auf dem Zielsystem gar nicht existiert. Solange git pull der Deployment-Mechanismus ist, liegt die vollständige Projektgeschichte auf dem Webserver - und jede künftige Fehlkonfiguration macht sie wieder lesbar. Fünf Bausteine bringen das Deployment in einen Zustand, in dem die Serverregel nur noch Absicherung ist.

1. Build-Artefakt statt Arbeitskopie. Der Buildprozess erzeugt ein Verzeichnis oder Archiv, das ausschließlich die auszuliefernden Dateien enthält - ohne .git, ohne Tests, ohne Fixtures, ohne Entwicklungsabhängigkeiten.
2. Docroot auf das Unterverzeichnis richten. Der Webserver zeigt auf public/, web/ oder dist/, nicht auf die Projektwurzel. Damit liegen .env, composer.json, vendor/ und .git strukturell außerhalb der Auslieferung - selbst ohne jede Sperrregel.
3. Release-Verzeichnisse mit Symlink. Jedes Release landet in einem eigenen Ordner, ein Symlink current zeigt auf den aktiven Stand. Das macht Rollbacks atomar und verhindert halbfertige Zustände im Docroot.
4. Übertragung mit Ausschlussliste. Statt eines Repository-Abgleichs auf dem Server erfolgt der Transfer per rsync oder Upload mit expliziter Ausschlussliste für .git, node_modules, .env, *.bak und Archivformate.
5. Keine Bearbeitung auf dem Produktivsystem. Kein cp config.php config.php.bak, keine Editor-Sitzungen, die .swp-Dateien hinterlassen. Änderungen entstehen im Repository und kommen über ein Release - nicht umgekehrt.

Zwei kleine Dateien tragen dabei unverhältnismäßig viel bei: .dockerignore verhindert, dass .git beim Image-Bau mitkopiert wird, und export-ignore-Einträge in .gitattributes halten Testdaten und Entwicklungswerkzeuge aus git archive-Exporten heraus. Beides kostet Minuten und schließt eine ganze Fehlerklasse.

Secrets gehören außerhalb des Docroots

Die zweite Hälfte des Problems sind die Zugangsdaten selbst. Eine .env-Datei ist nicht deshalb gefährlich, weil sie existiert, sondern weil sie an einem Ort liegt, den ein Webserver ausliefern kann. Vier Prinzipien halten sie außerhalb der Reichweite.

Der IT-Grundschutz des BSI verankert diese Anforderungen im Baustein APP.3.1 Webanwendungen und Webservices. Die Anforderung A12 verlangt eine sichere Konfiguration und ausdrücklich, sicherheitsrelevante Informationen aus Fehlermeldungen und Antworten herauszuhalten (BSI IT-Grundschutz, APP.3.1). A14 adressiert den Schutz vertraulicher Daten, A21 die sichere HTTP-Konfiguration und A22 Penetrationstest und Revision als wiederkehrende Prüfung (BSI IT-Grundschutz, APP.3.1). Genau diese vier Anforderungen decken den hier beschriebenen Fall ab - von der Konfiguration über die Auslieferung bis zur regelmäßigen Nachprüfung.

Wer ohnehin eine Komponentenliste führt, sollte die Deployment-Artefakte dort mitdenken. Der Beitrag zur Software-Stückliste nach CRA beschreibt, wie aus dem Inventar eine belastbare Grundlage für Schwachstellenbewertung wird - und dieselbe Inventarpflege beantwortet die Frage, welche Dateien ein Release überhaupt enthalten darf.

Nach jedem Release extern nachprüfen

Einmalige Prüfungen altern schlecht. Eine Serverkonfiguration wird migriert, ein CDN-Regelsatz wird überschrieben, eine Staging-Umgebung wird aufgesetzt und anschließend nicht gehärtet, ein Dienstleister spielt eine alte .htaccess zurück. Jeder dieser Vorgänge kann eine Sperre wieder öffnen, ohne dass es jemandem auffällt - denn im Betrieb ändert sich nichts Sichtbares.

Der Nachprüf-Lauf gehört deshalb an das Release und danach in ein festes Intervall. Was er leisten muss, ist überschaubar, aber präzise.

• Von außen, über die öffentliche Adresse. Ein Test auf dem Server selbst umgeht CDN, Load Balancer und Firewall - also genau die Ebenen, an denen Regeln hängen oder fehlen.
• Alle Hostnamen einzeln. Apex-Domain, www, Staging-Subdomains, alte Domains mit Weiterleitung und gegebenenfalls die Origin-Adresse hinter dem CDN.
• Inhalt statt Statuscode. /.git/HEAD auf ref: prüfen, /.env auf KEY=VALUE-Muster, .DS_Store auf die Dateisignatur. Ein 200 mit Fehlerseite ist kein Fund, ein 200 mit Inhalt sehr wohl.
• HTTP und HTTPS getrennt. Manche Sperrregeln stehen nur im TLS-vHost, während der Klartext-vHost unverändert ausliefert.
• Verzeichnislisten mitprüfen. /backup/, /alt/, /uploads/, /tmp/ und /logs/ auf aktives Directory-Listing testen.
• Antwort-Header auswerten. Server-Version, X-Powered-By und Framework-Signaturen verraten den Technologiestand und lenken gezielte Folgeanfragen.

Automatisieren lässt sich das gut, weil die Prüfung zustandslos ist: eine Liste von Pfaden, eine Liste von Hosts, ein Vergleich mit dem erwarteten Ergebnis. Genau so arbeitet die kontinuierliche Prüfung in XICTRAQ - der automatisierte Website-Audit beschreibt das Prinzip, und die Alarmierung über E-Mail, Slack und Webhooks sorgt dafür, dass eine neu geöffnete Datei nicht bis zum nächsten Quartalsbericht wartet.

Wer nach NIS2 oder dem Cyber Resilience Act in der Pflicht steht, sollte den Nachweis gleich mitdenken: Eine dokumentierte, wiederkehrende Prüfung ist Teil der geforderten technischen Maßnahmen. Welche Fristen und Zuständigkeiten dabei gelten, ordnet der Beitrag zur NIS2-Registrierung und der Verantwortung der Geschäftsleitung ein. Und wer parallel KI-Funktionen auf der Website betreibt, findet die dazugehörigen Offenlegungspflichten im Beitrag zur Transparenzpflicht nach dem AI Act für Website-Chatbots.

Sofortmaßnahmen bei abgeflossenen Zugangsdaten

Wenn die Prüfung einen Treffer liefert, gilt eine einzige Grundregel: rotieren statt löschen. Jeder Zugangsdatensatz, der jemals in einer öffentlich abrufbaren Datei oder in der Historie eines öffentlich lesbaren Repositories stand, ist als bekannt zu behandeln - unabhängig davon, ob ein Zugriff nachweisbar ist. Das Löschen der Datei entfernt die Kopie, nicht die Kenntnis.

1. Auslieferung sofort schließen. Serverregel setzen, Datei entfernen, Konfiguration neu laden. Dieser Schritt kostet Minuten und stoppt den weiteren Abfluss.
2. Zugangsdaten nach Wirkung rotieren. Reihenfolge: Deploy-Keys und Repository-Token, Datenbankzugänge, Mail- und SMTP-Zugänge, Zahlungs- und API-Schlüssel, Administrationskonten. Alte Schlüssel explizit widerrufen, nicht nur überschreiben.
3. Zugriffsprotokolle auswerten. Anfragen auf /.git/, /.env und Backup-Pfade im gesamten verfügbaren Zeitraum suchen. Erfolgreiche Abrufe mit Status 200 sind die relevanten Einträge, nicht die 404er.
4. Nach Persistenz suchen. Neue oder geänderte Dateien im Docroot, unbekannte Administrationskonten, zusätzliche Cronjobs, veränderte Weiterleitungen und fremde Skript-Einbindungen.
5. Datenbestand bewerten. Wurde ein Datenbank-Abzug ausgeliefert, sind personenbezogene Daten betroffen. Damit beginnt die Frist für die Meldung an die Aufsichtsbehörde nach Artikel 33 DSGVO - 72 Stunden ab Kenntnis.
6. Historie bereinigen und ersetzen. Secrets aus der Repository-Historie zu entfernen ist aufwendig und schützt nicht rückwirkend. Der wirksame Schritt bleibt der Austausch der Schlüssel.
7. Vorgang dokumentieren. Zeitpunkt der Entdeckung, betroffene Pfade, rotierte Zugangsdaten, Prüfergebnisse. Diese Dokumentation ist die Grundlage für Meldepflichten und für die Nachbereitung.

Wie die Schritte in einen belastbaren Ablauf gebracht werden, beschreibt der Website-Notfallplan in sieben Schritten. Wer zusätzlich prüfen will, ob nach dem Vorfall Dateien im Auslieferungspfad verändert wurden, findet im Screenshot-Changelog und Visual-Diff sowie in der Überwachung eingebundener Skripte die passenden Werkzeuge.

Vergessene Dateien gehören auf die Prüflisten

Die Zahlen aus dem internetweiten Scan sind unangenehm konkret: 4,96 Millionen Server mit öffentlich erreichbaren .git-Metadaten, 252.733 davon mit aktiven Zugangsdaten in der ausgelieferten Konfiguration, Deutschland unter den drei am stärksten betroffenen Ländern (Security Affairs, 06.02.2026). Das ist keine Frage mangelnder Kompetenz. Es ist eine Frage fehlender Rückkopplung: Niemand sieht, was der Webserver ausliefert, solange niemand von außen danach fragt.

Der Aufwand für die Gegenmaßnahme steht dazu in keinem Verhältnis. Eine Serverregel ist in zehn Minuten geschrieben. Ein Docroot auf das public/-Verzeichnis umzustellen ist Routine. Ein Build-Artefakt statt einer Arbeitskopie auszuliefern ist eine einmalige Umstellung der Pipeline. Und eine automatisierte Nachprüfung nach jedem Release kostet keine Aufmerksamkeit, solange sie nichts findet.

Was bleibt, ist die Gewohnheit. Sicherheitsarbeit an Websites scheitert selten an fehlendem Wissen, sondern daran, dass Prüfungen einmalig stattfinden und Konfigurationen sich danach weiterbewegen. Die Klassiker aus der Website-Sicherheits-Checkliste und die Risikokategorien der OWASP Top 10:2025 helfen bei der Einordnung - aber wirksam wird beides erst, wenn der Abgleich zwischen Soll und Ist regelmäßig läuft.

Ein guter nächster Schritt ist unspektakulär: Rufen Sie https://ihre-domain.de/.git/HEAD auf. Danach /.env. Danach dieselben Pfade auf jeder Subdomain, die Sie betreiben. Wenn alles mit 404 antwortet, haben Sie fünf Minuten investiert. Wenn nicht, haben Sie den wichtigsten Fund des Quartals gemacht. Der Security-Scan übernimmt diese Prüfung danach dauerhaft, und in der Live-Demo lässt sich das Ergebnis ohne Anmeldung ansehen; die Tarifübersicht zeigt, ab welchem Umfang die kontinuierliche Prüfung enthalten ist.