Alle Guides
Schweregrad KritischFehlkonfigurationen

Offene Datenbank-Backups: was passiert, wenn /backup.sql erreichbar ist

Datenbank-Backups — .sql-Dateien, komprimierte Dumps, Zip-Archive der Datenbank — werden manchmal direkt in einem per Web erreichbaren Verzeichnis erstellt und dort liegen gelassen. Ein einziger erfolgreicher Request auf /backup.sql oder /dump.sql liefert einem Angreifer jede Zeile jeder Tabelle, ohne deine Anwendungslogik überhaupt zu berühren.

Was es ist

Backup-Skripte, Hosting-Control-Panels und manuelle Export-Tools schreiben Dump-Dateien häufig mit vorhersehbaren Namen: backup.sql, dump.sql, database.sql, db.sql.gz, backup.zip. Landen diese im Web-Root und blockiert der Server sie nicht explizit, werden sie zu ganz normalen herunterladbaren Dateien. Angreifer betreiben automatisierte Scans, die Dutzende dieser gängigen Namen bei jedem erreichbaren Host abfragen.

AppSafe prüft die häufigsten Pfade — /backup.sql, /dump.sql, /database.sql, /db.sql.gz und weitere — und meldet jeden, der eine 200-Antwort mit Inhalt liefert, der wie ein SQL-Dump oder ein Archiv aussieht. Der Check erkennt sowohl Klartext-SQL als auch komprimierte Formate.

Warum es wichtig ist

Ein SQL-Dump enthält jede Zeile jeder Tabelle zum Zeitpunkt seiner Erstellung: Nutzerkonten, Passwort-Hashes, E-Mail-Adressen, personenbezogene Daten, Session-Tokens, Zahlungshistorie und internen Anwendungszustand. Einen Dump herunterzuladen ist ein einziger HTTP-Request, der keine Spur in deinen Anwendungslogs hinterlässt — der Webserver liefert ihn aus wie jede statische Datei.

Anders als einen geleakten API-Key kannst du eine geleakte Datenbank nicht rotieren. Hat jemand eine Kopie deiner users-Tabelle, ist das Datenleck für diese Nutzer endgültig. Je nach Inhalt des Dumps drohen meldepflichtige Datenschutzverletzungen nach DSGVO, CCPA oder HIPAA — samt dem Aufwand, jeden betroffenen Nutzer zu benachrichtigen.

So behebst du es

Backups aus dem Web-Root verschieben

Die richtige Lösung ist, Backup-Dateien in ein Verzeichnis zu schreiben, das der Webserver nicht erreichen kann — einen Pfad wie /var/backups/ oder einen Object-Storage-Bucket mit privaten ACLs, kein Unterverzeichnis von /var/www/. Überprüfe alle Cronjobs und Backup-Skripte und passe den Zielpfad an.

Gängige Backup-Endungen in nginx blockieren

Als Defense-in-Depth-Maßnahme verweigerst du Requests auf SQL-Dateien und gängige Archiv-Endungen auf Server-Ebene — unabhängig davon, wo die Dateien liegen.

location ~* \.(sql|sql\.gz|bak|dump|tar|tar\.gz|tar\.bz2|zip)$ {
  deny all;
  return 404;
}
Dump-Dateien im Web-Root löschen

Findest du eine offene Datei, lösche sie sofort. Untersuche dann, wie sie dorthin gekommen ist — korrigiere das Skript oder den Prozess, der sie abgelegt hat, damit sie beim nächsten geplanten Lauf nicht wieder auftaucht.

Prüfen, ob die Pfade 404 liefern

Bestätige nach dem Aufräumen, dass die gängigen Pfade blockiert sind.

for path in /backup.sql /dump.sql /database.sql /db.sql.gz; do
  code=$(curl -so /dev/null -w "%{http_code}" "https://yourdomain.com$path")
  echo "$path → $code"
done
# Every line must print 404

FAQ

Woher sollte ein Angreifer wissen, dass er /backup.sql auf meiner Website ausprobieren soll?

Er zielt nicht gezielt auf dich. Automatisierte Scanner fragen ununterbrochen Dutzende gängiger Backup-Namen bei Millionen von Hosts ab. Eine vorhandene Datei liefert 200 und wird heruntergeladen, bevor du überhaupt wüsstest, dass du nachsehen solltest.

Die Datei lag nur eine Stunde dort. Ist der Schaden schon passiert?

Möglicherweise. Automatisierte Scans laufen rund um die Uhr, und Dateien werden oft innerhalb von Minuten nach ihrem Erscheinen gefunden. Wenn du Zugriffslogs hast, prüfe, ob der Pfad abgefragt wurde — falls ja, behandle es als bestätigtes Datenleck.

Kann ich die Datei nicht einfach mit einem Passwort schützen, statt sie zu verschieben?

Basic Auth für eine einzelne Datei ist fragil und leicht falsch zu konfigurieren. Die richtige Antwort ist, die Datei vollständig aus jedem per Web erreichbaren Ort zu entfernen. Backups gehören an einen Ort, den der HTTP-Server nicht erreichen kann.

Ist deine App betroffen?

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

Meine App gratis scannen

Aus dem Blog

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.

Verwandte Guides

Offene Verzeichnis-Indizes: wenn dein Dateiserver alles auflistet

Ein Dateiserver, der seinen Inhalt auflistet, liefert Angreifern ein kostenloses Inventar.

Offengelegte .env-Dateien: wie Angreifer deine Secrets finden

Eine einzige erreichbare .env kann deinen gesamten Stack preisgeben.

Supabase Row Level Security (RLS): sichere deine Tabellen ab

Dein anon key ist öffentlich. RLS ist das Einzige, was zwischen ihm und deinen Daten steht.

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

Ein erreichbares /.git liefert deine komplette Codebasis samt Commit-Historie aus.