Schweregrad KritischFehlkonfigurationen

Offenes .git-Verzeichnis: das Quellcode-Leck, das sich gut sichtbar versteckt

Wenn ein Webserver das .git-Verzeichnis zusammen mit deinen Anwendungsdateien ausliefert, kann ein Angreifer genug Objekte herunterladen, um deinen vollständigen Quellcode zu rekonstruieren — einschließlich jedes Secrets, das jemals committet wurde, selbst wenn es in einem späteren Commit entfernt wurde. AppSafe stuft das als kritisch ein.

Was es ist

Git speichert das komplette Repository — jede Datei, jeden Commit, jede Branch-Spitze — in einem versteckten .git-Verzeichnis im Projekt-Root. Landet dieses Verzeichnis in deinem Web-Root und blockiert dein Server den Zugriff nicht, sind die Dateien unter /.git/config, /.git/HEAD und der Objektspeicher unter /.git/objects/ öffentlich herunterladbar.

Den vollständigen Quellcode aus einem offenen .git-Verzeichnis zu rekonstruieren, ist einfach. Tools wie git-dumper holen den Index und ziehen dann jedes referenzierte Objekt nach, sodass ein voll funktionsfähiger Checkout entsteht. Angreifer brauchen dafür keinen Shell-Zugang — nur einen Browser.

Warum es wichtig ist

Dein Quellcode enthält mit großer Wahrscheinlichkeit Informationen, die das Risiko erhöhen: hartcodierte API-Keys (oft in älteren Commits), Datenbankschemas, interne Endpunkt-Pfade, Geschäftslogik und Auth-Flows. Selbst wenn aktuell kein Secret committet ist, steckt die Historie voller Material, das Angreifer ausnutzen können.

Die Git-Historie ist bewusst permanent. Ein Secret, das vor Jahren committet und dann entfernt wurde, lebt weiterhin im Objektspeicher und wird mit allem anderen heruntergeladen. Es zu rotieren, ist der einzige Weg, es unschädlich zu machen.

So behebst du es

.git in nginx blockieren

Verweigere alle Requests, deren Pfad mit /.git/ beginnt. Gib 404 statt 403 zurück, damit du nicht bestätigst, dass das Verzeichnis existiert.

location ~ /\.git {
  deny all;
  return 404;
}

.git außerhalb des Web-Roots halten

Die zuverlässigste Lösung ist, das .git-Verzeichnis gar nicht erst in den Document Root zu deployen. Strukturiere deinen Build so, dass der kompilierte Output in ein separates public/-Verzeichnis geht, und deploye nur dieses, nicht den Projekt-Root.

Prüfen, ob es blockiert ist

Rufe nach dem Deploy des Fixes https://yourdomain.com/.git/config im Browser auf. Die Antwort sollte 404 sein, nicht der Inhalt deiner Git-Config. AppSafe prüft das bei jedem Scan erneut.

Alle jemals committeten Secrets rotieren

War das Verzeichnis erreichbar, betrachte jeden API-Key, jedes Passwort und jeden Token, der jemals in irgendeinem Commit auftauchte, als kompromittiert. Rotiere sie — den Commit zu entfernen reicht nicht, denn das Objekt existiert weiterhin in den Pack-Dateien, die ein Angreifer vielleicht schon heruntergeladen hat.

FAQ

Ich deploye auf eine Managed-Plattform (Vercel, Netlify, Fly.io) — bin ich gefährdet?

Managed-Plattformen, die aus dem Quellcode bauen, deployen in der Regel nur den Build-Output, sodass das .git-Verzeichnis nicht ausgeliefert wird. Höher ist das Risiko bei VPS-Deployments, Docker-Containern, die aus dem Projekt-Root gebaut werden, oder Static-Site-Exporten, bei denen der gesamte Working Tree kopiert wird.

Was prüft AppSafe genau?

AppSafe fragt /.git/config und /.git/HEAD ab und prüft, ob der Response-Body wie eine echte Git-Datei aussieht (passend zu den Mustern [core] oder ref:). Eine generische 200-Seite ohne Git-Inhalt wird nicht gemeldet.

Kann ich das .git-Verzeichnis einfach auf dem Server löschen?

Ja, wenn du nur die deployten Dateien zum Betrieb brauchst. Stelle aber sicher, dass dein Deployment-Prozess es beim nächsten Push nicht wieder hinkopiert. Es zusätzlich auf Webserver-Ebene zu blockieren, ist eine doppelte Absicherung für den Fall, dass Deployment-Skripte nicht konsistent sind.

Ist deine App betroffen?

AppSafe prüft dies und Dutzende weitere Probleme in einem kostenlosen Scan.

Meine App gratis scannen

Aus dem Blog

Falsche KI-Crawler jagen deine .env-Dateien. So prüfst du deine

Credential-Scanner leihen sich die Namen von KI-Crawlern, um an Allowlists vorbeizukommen, und sie fragen nach einer ganz bestimmten Datei: deiner .env. So prüfst du, ob deine erreichbar ist, und wie du sie absicherst.

Das Railway-Datenleck: So rotierst du die Secrets deiner App ohne Ausfallzeit

Railway hat alle Nutzer aufgefordert, ihre Umgebungsvariablen zu rotieren, nachdem Angreifer gezielt nach KI- und Plattform-API-Keys gesucht hatten. So prüfst du, ob du betroffen bist, rotierst alles, ohne deine App lahmzulegen — und sorgst dafür, dass das nächste Datenleck weniger wehtut.

PHP2Shell wird ausgenutzt: So prüfst du, ob deine App betroffen ist

Zwei kritische Bugs in PHP selbst gingen innerhalb weniger Tage von „Patch veröffentlicht“ zu „aktiv ausgenutzt“. So findest du heraus, ob etwas, das du hostest, eine betroffene Version nutzt — und was du heute dagegen tust.