wp-config.php härten: 10 Einstellungen im Check

In der wp-config.php stehen Ihr Datenbankpasswort, die Schlüssel, mit denen jedes Login-Cookie signiert wird, und die Schalter, die festlegen, ob Besucher Fehlermeldungen zu sehen bekommen. Die meisten Websitebetreiber haben die Datei nie geöffnet. Wer die wp-config.php härten will, findet hier einen Audit in zehn Punkten, der sich nur um diese eine Datei dreht. Zu jedem Prüfpunkt erhalten Sie die genaue Zeile, den richtigen Wert für den Livebetrieb, eine Methode zur Kontrolle und den Hinweis, wovor die Einstellung nicht schützt.

Was die wp-config.php steuert und wie Sie sie ohne weiße Seite bearbeiten

Die Datei enthält drei Arten von Angaben: erstens die Zugangsdaten zur Datenbank, zweitens acht Sicherheitsschlüssel und Salts, drittens Konstanten, die das Verhalten von WordPress verändern. Wer die Datei lesen kann, kommt in Ihre Datenbank. Wer sie beschreiben kann, führt bei jedem Seitenaufruf eigenen Code aus.

Gleichzeitig lässt sich keine Datei so leicht kaputtmachen. Ein einziges fehlendes Semikolon, und jeder Besucher sieht eine weiße Seite oder einen Fatal Error. Gehen Sie deshalb jedes Mal nach diesem Ablauf vor:

1. Laden Sie eine Kopie der aktuellen Datei auf Ihren Rechner herunter.
2. Bearbeiten Sie die Datei per SFTP oder SSH, nicht in einem browserbasierten Dateimanager oder über ein Plugin.
3. Wenn Sie Shell-Zugriff haben, führen Sie php -l wp-config.php aus. Die Ausgabe sollte „No syntax errors detected“ lauten.
4. Laden Sie Frontend und /wp-admin/ in einem privaten Browserfenster neu.
5. Geht etwas schief, spielen Sie Ihre Kopie wieder hoch. Danach korrigieren Sie die Änderung in Ruhe.
6. Funktioniert alles, löschen Sie alle temporären Kopien, die Sie auf dem Server angelegt haben (etwa wp-config.php.bak). Die Kopie auf Ihrem Rechner behalten Sie.

Auch die Position in der Datei zählt. Weit unten steht der Kommentar /* That's all, stop editing! Happy publishing. */, gefolgt von require_once ABSPATH . 'wp-settings.php';. Konstanten, die erst nach dieser Zeile definiert werden, kommen für die meisten Einstellungen zu spät. Setzen Sie jedes neue define() oberhalb des Kommentars. Die offizielle Referenz ist die Seite zur wp-config.php in der WordPress-Entwicklerdokumentation.

Geheimnisse: Datenbank-Zugangsdaten und eindeutige Sicherheitsschlüssel und Salts

Prüfpunkt 1: Datenbank-Zugangsdaten. DB_USER sollte ein Datenbankbenutzer sein, der ausschließlich für diese eine Website existiert, mit einem langen, zufälligen Passwort. Teilen sich drei Websites einen Datenbankbenutzer, legt ein Leck bei einer Website alle drei offen. Verwenden Sie hier nie das Passwort Ihres Hosting- oder Control-Panels. Dieser Prüfpunkt hilft nicht, wenn ein Angreifer bereits Code auf dem Server ausführt, denn dann kann er die Datei ohnehin lesen.

Prüfpunkt 2: Schlüssel und Salts. Es gibt acht davon: AUTH_KEY, SECURE_AUTH_KEY, LOGGED_IN_KEY, NONCE_KEY und die vier passenden _SALT-Konstanten. Sie müssen lang, zufällig und für diese Website einmalig sein. Steht bei einer davon noch put your unique phrase here, beheben Sie das heute. Einen frischen Satz erzeugen Sie unter api.wordpress.org/secret-key/1.1/salt/ und kopieren ihn über den alten Block. Mit WP-CLI genügt ein Befehl:

wp config shuffle-salts

Erneuern Sie die Salts nach einem Hack, wenn ein Administrator oder eine Agentur mit Dateizugriff ausscheidet oder wenn die Datei jemals offen lag.

Nach einer Kompromittierung ist das Erneuern dieser Geheimnisse nur ein Schritt einer größeren Bereinigung. Die vollständige Reihenfolge finden Sie unter WordPress-Malware entfernen.

Debug-Einstellungen für den Livebetrieb: WP_DEBUG, WP_DEBUG_DISPLAY und WP_DEBUG_LOG

Prüfpunkt 3: WP_DEBUG. Auf einer Live-Website gehört hier false hin. Angezeigte Fehler verraten Serverpfade, Plugin-Namen und manchmal Teile von Datenbankabfragen. Genau damit sucht sich ein Angreifer sein Ziel aus.

define( 'WP_DEBUG', false );

WP_DEBUG auf false schaltet allerdings nicht die PHP-eigene Einstellung display_errors ab. Hat Ihr Hoster sie aktiviert, können Warnungen trotzdem auf der Seite erscheinen. Fragen Sie beim Hoster nach oder prüfen Sie die PHP-Konfiguration, wenn Sie einen eigenen Server betreiben.

Prüfpunkt 4: Wenn Sie Logs brauchen, verstecken und verlagern Sie sie. Manchmal muss man im Livebetrieb debuggen. Dann gilt: Fehler nie auf der Seite anzeigen und nicht den Standard-Speicherort verwenden. WP_DEBUG_LOG auf true schreibt nach wp-content/debug.log, und diese Datei lässt sich oft öffentlich herunterladen. Geben Sie stattdessen einen Dateipfad außerhalb des Webroots an:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_DISPLAY', false );
define( 'WP_DEBUG_LOG', '/home/example/logs/wp-debug.log' );
@ini_set( 'display_errors', '0' );

Das Verzeichnis muss existieren und für den PHP-Benutzer beschreibbar sein. Prüfen Sie anschließend, dass kein altes Log mehr öffentlich erreichbar ist:

curl -I https://example.com/wp-content/debug.log

Erwartet ist 403 oder 404. Ein 200 bedeutet, dass jeder das Log lesen kann. Löschen Sie es.

Logs enthalten häufig E-Mail-Adressen, IP-Adressen und Formulareingaben und sind damit personenbezogene Daten im Sinne der DSGVO. Schalten Sie das Logging wieder ab, sobald Sie fertig sind, und löschen oder rotieren Sie alte Logdateien. Einzelheiten zu jeder Konstante stehen in der WordPress-Dokumentation zum Debugging.

HTTPS und Umgebung: FORCE_SSL_ADMIN und WP_ENVIRONMENT_TYPE

Prüfpunkt 5: FORCE_SSL_ADMIN. Damit laufen Login-Seite, Dashboard und Admin-Cookies ausschließlich über HTTPS:

define( 'FORCE_SSL_ADMIN', true );

Die Einstellung deckt nur den Adminbereich und die Anmeldung ab. Sie ersetzt weder eine serverseitige Weiterleitung von HTTP auf HTTPS für die gesamte Website, noch ist sie HSTS.

Prüfpunkt 6: WP_ENVIRONMENT_TYPE. Diese Einstellung teilt WordPress und Plugins mit, auf welcher Art von Website sie laufen. Gültige Werte sind production, staging, development und local. Standard ist production.

define( 'WP_ENVIRONMENT_TYPE', 'production' );

Die Einstellung hat durchaus spürbare Folgen. Im Core schaltet eine development-Umgebung WP_DEBUG ein, wenn Sie es nicht selbst definiert haben. Manche Plugins und Hoster lesen den Wert aus, um auf Nicht-Produktivsystemen den E-Mail-Versand zu unterbinden oder das Caching anzupassen. Wichtiger ist aber die Kennzeichnung. Eine Staging-Kopie enthält meist eine vollständige Kopie der echten Kunden- und Bestelldaten. Kennzeichnen Sie sie als staging und schützen Sie sie per HTTP-Authentifizierung oder IP-Beschränkung. Löschen Sie sie, wenn das Projekt abgeschlossen ist. Eine vergessene Staging-Subdomain mit der Kundendatenbank vom letzten Jahr ist eine häufige Ursache für Datenlecks.

Dateieditor und Dateiänderungen: DISALLOW_FILE_EDIT und DISALLOW_FILE_MODS

Prüfpunkt 7: Diese Zeile gehört in jede Website:

define( 'DISALLOW_FILE_EDIT', true );

Sie entfernt die Theme- und Plugin-Dateieditoren aus dem Dashboard. Ein gestohlener Admin-Login lässt sich dann nicht mehr mit ein paar Klicks in ausgeführten Code verwandeln. Einen Angreifer, der ein Plugin hochladen kann, hält sie nicht auf.

Prüfpunkt 8: DISALLOW_FILE_MODS geht weiter. Die Konstante blockiert zusätzlich das Installieren und Aktualisieren von Plugins und Themes über das Dashboard und schaltet die automatischen Hintergrund-Updates ab. Aktivieren Sie sie erst, wenn Sie einen anderen Update-Weg haben, etwa WP-CLI, eine Deployment-Pipeline oder vom Hoster verwaltete Updates. Andernfalls haben Sie die Website gerade auf dem heutigen, angreifbaren Versionsstand eingefroren. Beide Einstellungen und den passenden Update-Ablauf behandelt der Beitrag DISALLOW_FILE_EDIT: den WordPress-Dateieditor deaktivieren.

Dateirechte, Speicherort und vergessene Kopien der wp-config.php

Prüfpunkt 9: Dateirechte. Der richtige Wert hängt davon ab, unter welchem Benutzer PHP läuft:

• 400 oder 440: wenn der Eigentümer der Datei ein anderer Benutzer ist als PHP. Die Gruppe muss den PHP-Benutzer enthalten, der dann nur Lesezugriff braucht.
• 600: wenn PHP als Eigentümer der Datei läuft, wie es bei PHP-FPM-Pools pro Account üblich ist.

Vermeiden Sie 644 auf Shared Hosting, weil andere Accounts auf demselben Server die Datei unter Umständen lesen können. 777 ist nie richtig.

ls -l wp-config.php
chmod 440 wp-config.php

Eigentümer und Rechte für den Rest der Installation behandelt der Beitrag zu Web-Shells und Dateirechten.

Die Datei zu verschieben, und zwar ein Verzeichnis oberhalb des Webroots, ist zulässig. WordPress sucht dort automatisch, sofern im übergeordneten Ordner keine eigene WordPress-Installation liegt. Der Gewinn ist gering. Er zählt nur, wenn PHP ausfällt und der Server .php-Dateien als reinen Text ausliefert. Machen Sie es, wenn es sich einfach umsetzen lässt, aber verbuchen Sie es nicht als Lösung.

Prüfpunkt 10: vergessene Kopien. Das ist das größere und häufigere Risiko. Dateien wie wp-config.php.bak, wp-config.php.old, wp-config.php.save, wp-config.php~ oder eine Swap-Datei des Editors wie .wp-config.php.swp enden nicht auf .php. Der Webserver liefert sie unter Umständen als Klartext aus, samt Datenbankpasswort. So finden Sie sie:

find /var/www/example -name '*wp-config*' -type f

Übrig bleiben dürfen nur wp-config.php und die harmlose wp-config-sample.php. Löschen Sie den Rest. Umbenennen hilft nicht. War eine Kopie über das Web erreichbar, erneuern Sie zusätzlich Datenbankpasswort und Salts.

Der 10-Punkte-Check der wp-config.php in einer Tabelle

Ein sauberes Ergebnis hier sagt nichts über angreifbare Plugins, schwache Admin-Passwörter oder eine veraltete PHP-Version aus. Dafür gibt es die WordPress-Sicherheitscheckliste.

Das Plugin Security Audit & Compliance von secaudit.eu enthält einen Scan von Härtung und Konfiguration und sucht nach offenliegenden Geheimnissen und Dateien, etwa zurückgebliebenen Backups. Außerdem bietet es einen optionalen Schalter, mit dem Sie die Dateieditoren im Dashboard deaktivieren → secaudit.eu

Ihr nächster Schritt: Laden Sie jetzt eine Kopie der wp-config.php herunter und führen Sie den find-Befehl nach vergessenen Kopien aus. Das dauert zwei Minuten und deckt genau die Schwachstelle ab, die am häufigsten übersehen wird.

FAQ

Legt das Ändern der Salts meine Website lahm?

Nein. Inhalte, Einstellungen und Passwörter bleiben unverändert. Jeder angemeldete Benutzer wird abgemeldet und muss sich neu anmelden. Sagen Sie Ihren Redakteuren und Shop-Kunden also vorher Bescheid.

Sollte ich bei einer bestehenden Website das Tabellenpräfix ändern?

In der Regel nicht. Ein eigenes Präfix bringt kaum echten Schutz, und auf einer Live-Website müssten Sie dafür Tabellen umbenennen und Einträge in den Tabellen options und usermeta anpassen. Ein Fehler kann sämtliche Benutzer aussperren. Lassen Sie es, sofern Sie die Website nicht ohnehin neu aufbauen.

Kann ein Plugin die wp-config.php für mich verwalten?

Manche können das. Ein Plugin mit Schreibzugriff auf die wp-config.php ist aber selbst ein Risiko: Jede Sicherheitslücke darin wird zum Schreibzugriff auf Ihre sensibelste Datei. Bearbeiten Sie die Datei lieber von Hand per SFTP oder SSH und behalten Sie eine Kopie der letzten funktionierenden Version.