WordPress Debug-Log absichern

Wenn WordPress-Debugging aktiviert ist, werden Fehler und Warnungen in eine Log-Datei unter /wp-content/debug.log geschrieben. Das ist während der Entwicklung extrem nützlich. Auf einer Produktionsseite ist ein öffentlich zugängliches Debug-Log jedoch ein ernstes Sicherheitsrisiko. Jeder, der die URL kennt, kann es lesen, und es enthält oft weit mehr sensible Informationen, als den meisten Seitenbetreibern bewusst ist.

Was das Debug-Log enthält

Die debug.log-Datei ist nicht einfach nur eine Liste von PHP-Warnungen. Je nach Konfiguration deiner Seite und den installierten Plugins kann sie enthalten:

• PHP-Fehler und Warnungen: Diese beinhalten Dateipfade, Zeilennummern und Funktionsnamen. Ein Angreifer kann diese Informationen nutzen, um die Verzeichnisstruktur deines Servers zu kartieren und verwundbaren Code zu identifizieren.
• Datenbank-Query-Fehler: Fehlgeschlagene Queries enthalten manchmal Tabellennamen, Spaltennamen und sogar Fragmente der abgefragten Daten. Das gibt Angreifern Einblick in dein Datenbankschema.
• Plugin- und Theme-Fehler mit Stack Traces: Stack Traces verraten, welche Plugins du verwendest, deren Versionen und wie sie interagieren. Das ist wertvoll für die Planung gezielter Angriffe gegen bekannte Plugin-Schwachstellen.
• API-Schlüssel und Zugangsdaten: Schlecht programmierte Plugins loggen manchmal API-Antworten oder Verbindungsfehler, die Authentifizierungs-Tokens, API-Schlüssel oder sogar Passwörter im Klartext enthalten.
• Benutzerdaten und E-Mail-Adressen: Fehler im Zusammenhang mit Benutzerregistrierung, Formularübermittlungen oder E-Mail-Versand können persönliche Daten wie Namen, E-Mail-Adressen und Formulareingaben enthalten.
• Dateisystempfade: Jeder PHP-Fehler enthält den vollständigen Serverpfad zur Datei, in der er aufgetreten ist. Das offenbart deine Hosting-Verzeichnisstruktur, deinen Benutzernamen und manchmal deinen Hosting-Anbieter.

Warum das Debug-Log öffentlich zugänglich ist

Standardmäßig speichert WordPress debug.log im wp-content-Verzeichnis. Dieses Verzeichnis wird von deinem Webserver genauso ausgeliefert wie jeder andere Ordner in deiner WordPress-Installation. Wenn du den Zugriff nicht ausdrücklich blockiert hast, kann jeder https://deineseite.de/wp-content/debug.log im Browser eingeben und die Datei lesen.

Viele Hosting-Anbieter blockieren diesen Pfad nicht standardmäßig. Und weil die Datei ohne automatische Rotation mit der Zeit wächst, kann sie Monate oder sogar Jahre an sensiblen Fehlerdaten ansammeln.

Wie Angreifer Debug-Logs finden

Automatisierte Scanner prüfen routinemäßig /wp-content/debug.log auf jeder WordPress-Seite, die sie finden. Es ist einer der ersten Pfade, die Sicherheits-Scanning-Tools testen. Manche Angreifer prüfen auch häufige Variationen:

• /wp-content/debug.log (Standardort)
• /debug.log (manchmal fehlkonfiguriert)
• /wp-content/uploads/debug.log (eine weitere häufige Fehlkonfiguration)
• /error_log oder /error.log (generische Fehlerlog-Namen)

Diese Scans sind günstig, schnell und vollständig automatisiert. Wenn dein Debug-Log zugänglich ist, wird es gefunden.

Zugriff per .htaccess blockieren (Apache)

Wenn dein Server Apache verwendet, füge diese Regel zur .htaccess-Datei in deinem wp-content-Verzeichnis hinzu:

    Order allow,deny
    Deny from all

Das weist Apache an, alle HTTP-Anfragen für die debug.log-Datei abzulehnen. Die Datei existiert weiterhin auf der Festplatte und PHP kann weiterhin hineinschreiben, aber niemand kann sie über einen Browser herunterladen. Wenn du vorsorglich alle Log-Dateien blockieren möchtest, kannst du eine breitere Regel verwenden:

    Order allow,deny
    Deny from all

Zugriff per Nginx blockieren

Für Nginx-Server füge diesen Location-Block zu deiner Server-Konfiguration hinzu:

location ~* /debug\.log$ {
    deny all;
    return 404;
}

Die Rückgabe einer 404 statt einer 403 ist eine bewusste Entscheidung. Eine 403-Antwort (Forbidden) verrät dem Angreifer, dass die Datei existiert, aber geschützt ist. Eine 404-Antwort (Not Found) gibt nichts preis. Lade nach dem Hinzufügen dieser Regel die Nginx-Konfiguration mit sudo nginx -s reload neu.

Log-Datei außerhalb des Web-Roots verschieben

Der sicherste Ansatz ist, das Debug-Log in einem Verzeichnis zu speichern, das dein Webserver gar nicht ausliefern kann. Setze in deiner wp-config.php die WP_DEBUG_LOG-Konstante auf einen absoluten Pfad außerhalb deines Web-Roots:

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', '/home/deinuser/logs/wp-debug.log');
define('WP_DEBUG_DISPLAY', false);

Das Verzeichnis /home/deinuser/logs/ muss existieren und vom Webserver-Prozess beschreibbar sein. WP_DEBUG_DISPLAY auf false zu setzen ist genauso wichtig: Es verhindert, dass PHP-Fehler direkt auf deinen Seiten angezeigt werden, wo Besucher (und Angreifer) sie sehen könnten.

Debug-Modus auf Produktionsseiten deaktivieren

Auf einer Live-Produktionsseite sollte Debugging fast immer ausgeschaltet sein. Es gibt selten einen guten Grund, es dauerhaft aktiviert zu lassen. Setze diese Werte in der wp-config.php:

define('WP_DEBUG', false);
define('WP_DEBUG_LOG', false);
define('WP_DEBUG_DISPLAY', false);

Wenn du ein Problem auf der Produktion debuggen musst, aktiviere den Debug-Modus vorübergehend, reproduziere das Problem, prüfe das Log und deaktiviere ihn dann sofort wieder. Lass Debugging niemals "nur für den Fall" aktiviert. Das Risiko ist die Bequemlichkeit nicht wert.

Größe der Debug-Log-Datei überwachen

Wenn du Debugging auf einer Staging- oder Entwicklungsseite aktiviert lässt, überwache die Größe des Debug-Logs. Ohne Log-Rotation kann es auf Hunderte von Megabytes anwachsen und schließlich deine Festplatte füllen. Richte einen Cron-Job ein, um es zu rotieren oder zu kürzen:

# debug.log wöchentlich rotieren, 4 Backups aufbewahren
# Hinzufügen zu /etc/logrotate.d/wp-debug
/home/deinuser/logs/wp-debug.log {
    weekly
    rotate 4
    compress
    missingok
    notifempty
}

Was tun, wenn sensible Daten bereits offengelegt wurden

Wenn dein Debug-Log öffentlich zugänglich war und sensible Informationen enthielt, führe diese Schritte sofort durch:

• Debug-Log-Datei löschen: Entferne sie sofort vom Server.
• Alle API-Schlüssel und Zugangsdaten rotieren: Jeder API-Schlüssel, jedes Passwort und jeder Token, der im Log aufgetaucht ist, sollte als kompromittiert betrachtet werden. Generiere sie neu.
• Datenbank-Passwörter ändern: Wenn Datenbankverbindungsfehler geloggt wurden, könnten die Zugangsdaten offengelegt worden sein.
• Auf unbefugten Zugriff prüfen: Überprüfe deine Server-Zugriffslogs auf Anfragen an debug.log. Wenn jemand sie heruntergeladen hat, bewerte, welche Informationen erlangt wurden.
• Betroffene Benutzer benachrichtigen: Wenn persönliche Daten (E-Mails, Namen, Formularübermittlungen) geloggt wurden, hast du möglicherweise eine DSGVO-Pflicht, betroffene Personen zu benachrichtigen.

Mit InspectWP überprüfen

InspectWP prüft, ob /wp-content/debug.log auf deiner Seite öffentlich zugänglich ist. Nachdem du die Datei abgesichert hast (Zugriff blockiert, verschoben oder Debug-Modus deaktiviert), führe einen neuen InspectWP-Scan durch. Der Sicherheitsbereich des Berichts bestätigt, ob die Datei noch erreichbar ist. Falls die Warnung bestehen bleibt, leere alle serverseitigen Caches und überprüfe, ob deine .htaccess- oder Nginx-Regeln auf das richtige Verzeichnis angewendet werden.