Scanner für offengelegte Logs

Wie diese Prüfung funktioniert

Scanaris fordert sieben Pfade an, in die die gängigsten Anwendungen ihre Logs schreiben, wenn ihnen niemand etwas anderes sagt: /debug.log, /error.log, /error_log, /laravel.log, /storage/logs/laravel.log, /npm-debug.log und /wp-content/debug.log. Antwortet einer davon mit einer Textdatei, die nach einem Log aussieht, und nicht mit der generischen Seite deiner Website, öffnet er einen Befund mit mittlerem Schweregrad und dem Pfad. Logs enthalten selten die ganze Datenbank, daher nicht kritisch; aber wenige Dateien verraten so viel über das Innenleben deiner Seite.

Warum das wichtig ist

Ein Fehlerlog ist das Protokoll von allem, was schiefging: interne Serverpfade, Datei- und Funktionsnamen, exakte Bibliotheksversionen, gescheiterte Datenbankabfragen mit ihren Parametern, IP-Adressen der Nutzer, manchmal E-Mails oder Tokens, die in einer Anfrage auftauchten. Damit weiß jemand, der eine Schwachstelle sucht, genau, wo er hinschauen und welche Version er angreifen muss. Und das Log wächst: Jeder Tag der Offenlegung verrät mehr.

Warum das passiert

WordPress mit aktiviertem WP_DEBUG_LOG schreibt nach wp-content/debug.log, und das ist ein öffentlicher Ordner; das ist der häufigste Fall. Laravel hält seine Logs in storage/logs, das nicht erreichbar sein sollte, es aber ist, wenn der Server auf das Projekt-Root statt auf public/ zeigt. Apache auf Shared Hosting lässt error_log neben den Dateien der Seite liegen. Und npm-debug.log taucht auf, wenn eine Installation auf dem Server gescheitert ist und niemand aufgeräumt hat.

So behebst du es

• WordPress: in Produktion define('WP_DEBUG', false); in der wp-config.php. Wenn du das Log vorübergehend brauchst, verschieb es mit define('WP_DEBUG_LOG', '/privater/pfad/debug.log'); aus dem öffentlichen Ordner und lösch die aktuelle Datei.
• Laravel: Der Webserver muss auf den Ordner public/ des Projekts zeigen, nie auf das Root. So ist storage/ nicht mehr erreichbar. Und APP_DEBUG=false.
• Node und andere: Schreib Logs außerhalb des ausgelieferten Verzeichnisses und schick sie, wenn möglich, an einen Logging-Dienst. Lösch npm-debug.log und Ähnliches vom Server.
• Blockiere die Erweiterung serverseitig als zweite Barriere. In nginx: location ~* \.log$ { deny all; }. In Apache: <FilesMatch "\.log$"> Require all denied </FilesMatch>.
• Reduziere, was du in Produktion loggst: Level error statt debug, ohne vollständige Request-Bodies oder Tokens auszugeben.

Prüf, ob es behoben ist

for p in debug.log error.log error_log laravel.log storage/logs/laravel.log npm-debug.log wp-content/debug.log; do
  printf "%-28s " "$p"; curl -s -o /dev/null -w "%{http_code}\n" "https://deinedomain.de/$p"
done

Erwartet: 404 oder 403 überall. Wenn deine Seite eine Single-Page-App ist und mit 200 und ihrem HTML antwortet, ist das nicht das Log; öffne es zur Bestätigung.

Häufige Fragen

Mein Log enthält nichts Sensibles, nur PHP-Warnungen.

Diese Warnungen enthalten die vollständigen Serverpfade und die Plugin-Versionen, genau das, was ein Angreifer nutzt, um zu entscheiden, welchen Exploit er probiert. Und heute ist nichts Sensibles drin; morgen, mit einem neuen Fehler, kann es das sein.

Soll ich Logs komplett abschalten?

Nein. Sie dürfen nur nicht öffentlich sein. Logge, was du willst, in einen Ordner, den der Webserver nicht ausliefert, oder in einen externen Dienst.

Betrifft mich das auf Vercel oder Netlify?

Fast nie: Dort werden Logs nicht in öffentliche Dateien geschrieben, sondern im Dashboard eingesehen. Der Befund taucht vor allem auf selbst gehosteten Servern, bei WordPress und auf Shared Hosting auf.