Wie diese Prüfung funktioniert
Scanaris fordert eine Liste von Pfaden an, auf denen oft Dateien liegen bleiben, die nie auf einem öffentlichen Server sein sollten: .env, .env.local, .env.production, .git/config, .git/HEAD, wp-config.php, config.json, docker-compose.yml, backup.sql, phpinfo.php, .npmrc, Dockerfile, .gitlab-ci.yml, .aws/credentials, .ssh/id_rsa, web.config, adminer.php und .DS_Store. Ein 200 reicht nicht, um etwas zu melden: Viele Single-Page-Anwendungen antworten auf jeden Pfad mit 200 und ihrem HTML. Deshalb prüft der Scanner, ob der Inhalt echt aussieht, etwa dass eine .env Zeilen der Form SCHLUESSEL=wert enthält und kein HTML ist, oder dass .git/HEAD mit ref: beginnt. Der Schweregrad hängt von der Datei ab: kritisch bei .env, Datenbank-Dumps und privaten Schlüsseln; hoch bei .git und Serverkonfigurationen; niedrig bei .DS_Store oder einem Dockerfile.
Was ein Angreifer damit tut
Dasselbe wie der Scanner, nur gegen alle existierenden Domains. Eine erreichbare .env liefert auf einen Schlag die Datenbank-Zugangsdaten, die Zahlungsschlüssel und die E-Mail-Tokens. Ein offengelegtes .git-Verzeichnis erlaubt, das komplette Repository mit einem Kommandozeilen-Tool herunterzuladen, mit der gesamten Historie, einschließlich der Schlüssel, die in einem späteren Commit gelöscht wurden. Eine backup.sql ist deine ganze Datenbank, samt Nutzern und gehashten Passwörtern. Es ist einer der am einfachsten auszunutzenden und schwersten Fehler.
Warum es passiert
Zwei Ursachen. Die erste: Es wird der ganze Projektordner statt des Build-Ausgabeordners deployt, und alles im Repository wird ausliefbar. Die zweite: ein Webserver (nginx, Apache, IIS), der einen Ordner ausliefert, in dem auch entwickelt oder gesichert wird. Plattformen wie Vercel oder Netlify veröffentlichen nur den Ausgabeordner, weshalb sich der Fehler dort meist auf versehentlich nach public/ kopierte Dateien beschränkt.
Wie du es behebst
- Entferne die Datei und rotiere alles, was sie enthielt. War eine
.enverreichbar, ist jeder Schlüssel darin kompromittiert, auch wenn dich niemand gewarnt hat. - Deploye nur die Build-Ausgabe (
dist/,.output/,.next/), nie das Projekt-Root. In Express mussexpress.staticauf diesen Ordner zeigen. - Blockiere die Pfade auf dem Server als zweite Barriere. In nginx:
location ~ /\.(?!well-known) { deny all; }blockiert alles, was mit einem Punkt beginnt, außer.well-known; ergänze Regeln für*.sql,*.ymlund*.log. In Apache das Gegenstück mitFilesMatchundRequire all denied. - Prüf den public/-Ordner deines Projekts: Dort gehört nichts hin außer Bildern, Schriften oder Dateien, die zum Download gedacht sind.
- Schau in die Zugriffsprotokolle nach Anfragen auf
/.envoder/.gitmit Antwort 200, um zu wissen, ob jemand vor dir da war.
Prüf, ob es behoben ist
for p in .env .env.local .git/config .git/HEAD config.json backup.sql docker-compose.yml .npmrc; do
printf "%-20s " "$p"; curl -s -o /dev/null -w "%{http_code}\n" "https://deinedomain.com/$p"
doneErwartet: überall 404 oder 403. Ein 200 bei einer SPA kann das übliche HTML sein: Öffne es und bestätige, dass es nicht die echte Datei ist.
Häufige Fragen
Meine Website antwortet auf allen Pfaden mit 200. Gibt es Fehlalarme?
Nein. Der Scanner validiert den Inhalt, bevor er einen Fund öffnet; ein generisches HTML zählt nicht als .env.
Warum ist .DS_Store ein Fund, wenn es keine Geheimnisse enthält?
Weil es die Dateinamen des Ordners auflistet, auch die, die du von keiner Seite aus verlinkst. Eine kostenlose Landkarte für alle, die Backups oder vergessene Dateien suchen. Niedriger Schweregrad, aber entfernen lohnt sich.
Und die .well-known-Pfade?
Die müssen erreichbar sein: Dort liegen security.txt, Domain-Verifizierungen und Zertifikate. Die nginx-Regel im Beispiel nimmt sie von der Sperre aus.