Sicher loggen: Fehler protokollieren ohne Datenleck

Kurz gesagt: Logging in PHP mit Blick auf den Datenschutz heißt: sicherheitsrelevante Ereignisse vollständig festhalten, Passwörter, Tokens, Sitzungskennungen und sensible Kundendaten aber nie ins Log schreiben. Fehler gehören ins Protokoll, nicht auf den Bildschirm, Logs liegen außerhalb des Webroots und sind vor Änderung geschützt. Wie lange Logs bleiben, entscheiden Sie bewusst gemeinsam mit dem Datenschutzbeauftragten.

Zwischen Spurensicherung und Datenleck

Nach PHP2Shell rieten Fachmedien, Webserver-Logs ab dem 20.10.2026 aufzubewahren. Wer das umsetzen wollte, stellte oft zweierlei fest. Entweder waren die Logs längst rotiert und gelöscht. Oder sie enthielten Dinge, die dort nie hätten stehen dürfen: vollständige Formulareingaben, Passwörter aus fehlgeschlagenen Anmeldungen, API-Schlüssel in URLs.

Beides ist ein Problem. Ohne Logs lässt sich ein Vorfall kaum rekonstruieren. Mit zu viel Inhalt wird das Log selbst zum Ziel, denn wer Zugriff auf den Server erlangt, liest es gern mit. Gutes Logging liegt dazwischen: genug für die Spurensuche, so wenig wie möglich an schützenswerten Daten.

Was eine PHP-Anwendung protokollieren sollte

Das OWASP Logging Cheat Sheet nennt Ereignisse, die für Sicherheit und Nachvollziehbarkeit zählen. Für typische PHP-Anwendungen lassen sie sich so zusammenfassen:

Jeder Eintrag sollte die Fragen wann, wo, wer und was beantworten: Zeitstempel, Anwendung und Host, Quelladresse, Benutzerkennung, Art des Ereignisses und Ergebnis. Namen oder Mailadressen lassen sich oft maskieren oder durch eine interne Kennung ersetzen, ohne den Nutzen zu verlieren.

Zwei Quellen für ungewollte Daten im Log werden oft übersehen. Die erste sind URLs: Steht ein Token, ein Passwort-Reset-Schlüssel oder eine Mailadresse im Query-String, landet er automatisch im Access-Log des Webservers, in Proxy-Logs und im Browserverlauf. Solche Werte gehören in den Request-Body oder einen Header, nicht in die Adresse. Die zweite Quelle ist der Debug-Modus. Frameworks und Plugins schreiben im Debug-Betrieb oft vollständige Anfragen, Datenbankabfragen und Umgebungsvariablen mit. Bleibt dieser Modus nach einer Fehlersuche aktiv, wächst unbemerkt eine Datei mit genau den Informationen, die ein Angreifer sucht. Prüfen Sie nach jeder Fehlersuche, ob Debug-Ausgaben wieder abgeschaltet sind, und löschen Sie die dabei entstandenen Dateien.

Logging in PHP: die Grundeinstellungen

Die erste Ebene ist PHP selbst. In Produktion sollen Fehler protokolliert, aber nicht ausgegeben werden. Das Log liegt außerhalb des Webroots, damit es nicht über eine URL abrufbar ist.

; php.ini oder FPM-Pool für Produktion
display_errors = Off
display_startup_errors = Off
log_errors = On
error_log = /var/log/php/app-error.log

Warum sichtbare Fehler gefährlich sind, beschreibt Fehlerausgaben in der Produktion abschalten. Wie Fehler und Exceptions in PHP zusammenhängen, erklärt Fehler und Exceptions in PHP.

Die zweite Ebene ist die Anwendung. Viele Frameworks nutzen dafür eine Bibliothek nach dem Standard PSR-3 der PHP-FIG, der eine einheitliche Logger-Schnittstelle festlegt. Wichtig ist nicht die Bibliothek, sondern die Disziplin: Kontextdaten bewusst auswählen, statt ganze Anfragen oder Objekte ins Log zu schreiben.

<?php
// Eingaben vor dem Loggen entschärfen und maskieren
function logSicher(string $text): string {
    return mb_substr(str_replace(["\r", "\n"], ' ', $text), 0, 200);
}

function maskiereMail(string $mail): string {
    [$name, $domain] = array_pad(explode('@', $mail, 2), 2, '');
    return mb_substr($name, 0, 1) . '***@' . $domain;
}

$logger->warning('Anmeldung fehlgeschlagen', [
    'benutzer' => maskiereMail(logSicher($_POST['email'] ?? '')),
    'ip'       => $_SERVER['REMOTE_ADDR'] ?? '',
    // niemals: 'passwort' => $_POST['passwort']
]);

Log-Injection und manipulierte Einträge

Schreibt eine Anwendung Eingaben ungefiltert ins Log, kann ein Angreifer mit Zeilenumbrüchen gefälschte Einträge erzeugen. Das verwirrt die Auswertung und kann Spuren verdecken. Das OWASP Cheat Sheet empfiehlt strukturierte Formate wie JSON, das Entfernen oder Kodieren von Zeilenumbrüchen und eine Längenbegrenzung für Eingaben im Log.

Ebenso wichtig ist der Schutz der Logs selbst:

1. Ablage außerhalb des Webroots und mit Rechten, die der Webserver-Benutzer zum Schreiben, aber nicht zum Löschen alter Dateien braucht.
2. Kopie auf ein zweites System, etwa per Syslog über eine verschlüsselte Verbindung. Wer den Server übernimmt, soll die Spuren nicht einfach löschen können.
3. Lesezugriff beschränken und selbst protokollieren. Logs enthalten fast immer personenbezogene Daten.
4. Ausfall erkennen: Bleibt das Log plötzlich leer, ist das ein Warnsignal.
5. Uhrzeit abgleichen: Alle Server beziehen die Zeit aus derselben Quelle und schreiben eine eindeutige Zeitzone ins Log. Sonst lassen sich Einträge von Webserver, PHP und Datenbank nach einem Vorfall kaum zu einer Zeitleiste zusammenfügen.

Aufbewahrung und Datenschutz bewusst entscheiden

Wie lange Logs bleiben dürfen und müssen, ist eine Abwägung zwischen Sicherheitsinteresse, Datensparsamkeit und gesetzlichen oder vertraglichen Vorgaben. Art. 32 DSGVO verlangt dem Risiko angemessene technische und organisatorische Maßnahmen, unter anderem um Vertraulichkeit, Integrität und Verfügbarkeit der Systeme dauerhaft sicherzustellen; Protokollierung kann dazu beitragen. Gleichzeitig dürfen personenbezogene Daten nicht länger als nötig gespeichert werden.

Legen Sie deshalb eine Frist je Logart fest, schreiben Sie die Begründung auf und stimmen Sie beides mit Ihrem Datenschutzbeauftragten ab. Für eine laufende Untersuchung kann es nötig sein, Logs über die normale Frist hinaus zu sichern. Das sollte dann ebenfalls dokumentiert werden. Diese Seite ist allgemeine Information und keine Rechtsberatung; bei konkreten Fragen helfen Datenschutzbeauftragte und Anwalt. Wie Sie Logs nach einem Angriff auswerten, zeigt Webserver-Logs nach einem Angriff auswerten.

Wie hilft PHP SOS konkret?

• Wir prüfen Ihre bestehenden Logs auf Passwörter, Tokens und andere Daten, die dort nicht hingehören.
• Wir stellen PHP und Anwendung so ein, dass Fehler protokolliert, aber nicht angezeigt werden.
• Wir richten eine geschützte Kopie der Logs auf einem getrennten System ein.
• Über Security-Monitoring werten wir sicherheitsrelevante Einträge laufend aus und melden Auffälliges verständlich.

Fazit: Gute Logs sind sparsam beim Inhalt und großzügig beim Schutz. Wer heute festlegt, was protokolliert wird und was nie, hat im Ernstfall verwertbare Spuren und kein zusätzliches Datenleck.

Häufige Fragen

Quellen

• OWASP: Logging Cheat Sheet
• PHP-FIG: PSR-Standards
• PHP-Handbuch
• OWASP Top 10