wp-config.php härten: Salts, Dateibearbeitung und Debug-Einstellungen

Die Datei wp-config.php enthält die Zugangsdaten zur Datenbank, die geheimen Schlüssel für Anmelde-Cookies und die Schalter, mit denen WordPress Fehler anzeigt oder Dateien im Backend bearbeiten lässt. Wer sie liest, kann die Datenbank übernehmen; wer sie falsch konfiguriert, gibt Angreifern mit einem gestohlenen Admin-Passwort einen direkten Weg zur Codeausführung. Diese Anleitung zeigt, wie Sie die Datei mit wenigen, dokumentierten Einstellungen härten: Salts erneuern, Dateibearbeitung sperren, Debug-Ausgaben sicher setzen, HTTPS für die Anmeldung erzwingen und den Zugriff auf die Datei selbst einschränken. Jede Einstellung wurde in einer Testinstanz mit WordPress 7.1.2 geprüft.

Voraussetzungen

• WordPress: aktuelle Version, getestet mit WordPress 7.1.2, PHP 8.4 und Apache 2.4.
• Rolle: Administrator im WordPress-Backend, um die Wirkung zu prüfen.
• Dateizugriff: FTP/SFTP oder Dateimanager des Hosters, um wp-config.php und .htaccess zu bearbeiten. Für die Beispielbefehle SSH mit WP-CLI.
• HTTPS: ein gültiges Zertifikat für die Domain, bevor Sie FORCE_SSL_ADMIN setzen.
• Backup: eine Kopie der aktuellen wp-config.php und ein vollständiges Backup der Website. Ein Tippfehler in dieser Datei legt die ganze Website lahm.
• Texteditor ohne Formatierung: zum Beispiel der Editor Ihres FTP-Programms. Textverarbeitungen ersetzen gerade Anführungszeichen durch typografische, was PHP-Fehler auslöst.

Schritt 1: Datei sichern und Ausgangslage prüfen

Legen Sie vor jeder Änderung eine Kopie an, am besten außerhalb des Webverzeichnisses. Mit WP-CLI verschaffen Sie sich einen Überblick, welche Konstanten schon gesetzt sind. Der Befehl zeigt mit --fields=name,type nur die Namen, nicht die Werte, damit keine Passwörter im Terminalverlauf landen:

cp wp-config.php ~/wp-config.php.bak
wp config list --fields=name,type

Ändern Sie eigene Einträge immer oberhalb der Zeile /* That's all, stop editing! Happy publishing. */. Alles darunter lädt WordPress, und Konstanten, die erst danach gesetzt werden, wirken nicht mehr. WP-CLI fügt mit wp config set neue Konstanten automatisch an der richtigen Stelle ein und prüft die Syntax, daher ist es der sicherere Weg. Wie Sie Fehler nach einer missglückten Änderung eingrenzen, beschreibt die Anleitung WordPress-Update fehlgeschlagen: weiße Seite und kritischen Fehler beheben.

Verifizieren: Die Sicherungskopie existiert, und wp config list zeigt die Liste ohne Fehlermeldung.

Schritt 2: Salts und Schlüssel erneuern

Die acht Konstanten von AUTH_KEY bis NONCE_SALT dienen WordPress als Geheimnis für Anmelde-Cookies und Nonces. Laut Kommentar in der mitgelieferten Vorlage können Sie sie jederzeit ändern, um alle bestehenden Cookies ungültig zu machen; alle Benutzer müssen sich dann neu anmelden. Das ist nach einem Sicherheitsvorfall, nach dem Ausscheiden eines Mitarbeiters mit Admin-Zugang oder wenn die Werte je in einem Backup oder Ticket offen lagen sinnvoll.

wp config shuffle-salts

Im Labor meldete der Befehl „Success: Shuffled the salt keys.“ Ein zuvor gültiges Anmelde-Cookie wurde von wp_validate_auth_cookie() vorher mit Benutzer-ID 1 akzeptiert, danach mit false abgelehnt. Ohne SSH erzeugen Sie neue Werte über den offiziellen Schlüsselgenerator von WordPress.org und ersetzen die acht Zeilen in der Datei von Hand.

Planen Sie den Wechsel außerhalb der Arbeitszeit ein. Auch Redakteure und Shop-Kunden werden abgemeldet, und nicht gespeicherte Eingaben im Editor gehen verloren.

Hinweis für Docker-Installationen mit dem offiziellen Image: Dort liest wp-config.php die Schlüssel aus Umgebungsvariablen. Im Labor ersetzte shuffle-salts diese Zeilen durch feste Werte, danach gelten die Variablen nicht mehr für die Schlüssel.

Verifizieren: Nach dem Wechsel werden Sie beim nächsten Aufruf von /wp-admin/ zur Anmeldung geleitet, und die Anmeldung mit Ihrem Passwort funktioniert.

Schritt 3: Datei-Editor im Backend abschalten

WordPress enthält unter „Design > Theme-Datei-Editor“ und „Plugins > Plugin-Datei-Editor“ einen Editor für PHP-Dateien. Das Hardening-Kapitel der offiziellen Dokumentation nennt ihn als häufig erstes Werkzeug eines Angreifers mit Admin-Zugang, weil er direkt Code ausführen lässt. Eine Konstante schaltet ihn ab:

wp config set DISALLOW_FILE_EDIT true --raw

Das ergibt in der Datei diese Zeile:

define( 'DISALLOW_FILE_EDIT', true );

Laut Dokumentation entspricht das dem Entzug der Fähigkeiten edit_themes, edit_plugins und edit_files für alle Benutzer. Im Labor lieferte current_user_can( 'edit_plugins' ) für den Administrator danach false, während Installation und Update von Plugins weiter erlaubt blieben. Ein Nachteil entsteht nur, wenn Sie den Editor tatsächlich nutzen; Änderungen an Theme-Dateien gehören ohnehin in ein Child-Theme und per SFTP auf den Server. Die Dokumentation weist darauf hin, dass einzelne Plugins, die auf edit_plugins prüfen, dadurch eingeschränkt sein können.

Verifizieren: Die Menüpunkte „Theme-Datei-Editor“ und „Plugin-Datei-Editor“ sind im Backend verschwunden.

Schritt 4: Installation und Updates im Backend sperren (optional)

Mit DISALLOW_FILE_MODS geht WordPress einen Schritt weiter: Im Backend lassen sich keine Plugins und Themes mehr installieren oder aktualisieren, und der Datei-Editor ist ebenfalls gesperrt. Im Labor lieferten danach install_plugins, update_plugins und update_core für den Administrator false.

define( 'DISALLOW_FILE_MODS', true );

Das ist ein echter Trade-off. Die Sperre schützt vor dem Einspielen manipulierter Plugins über ein gekapertes Admin-Konto, blockiert aber auch alle Updates aus dem Backend und die automatischen Hintergrund-Updates; im Labor meldete der Auto-Updater mit gesetzter Konstante, dass er deaktiviert ist. Setzen Sie sie nur, wenn Updates verlässlich auf anderem Weg laufen, etwa per WP-CLI. Im Labor installierte und aktualisierte WP-CLI trotz der Konstante weiterhin Plugins. Ohne diesen zweiten Weg veraltet die Website, und das Risiko steigt, statt zu sinken.

Genau hier zeigt sich, dass Härtung laufende Pflege voraussetzt: Eine Website, die niemand aktualisiert, bleibt trotz guter Konfiguration angreifbar. Wer Updates und Sicherheit nicht selbst im Kalender halten möchte, kann sie abgeben: Die WordPress-Wartung von wordpressupdate.de übernimmt Updates von WordPress, Plugins und Themes, wöchentliche Backups auf externen Speicher sowie Einrichtung und Wartung einer Firewall.

Verifizieren: Ohne die Konstante zeigt „Dashboard > Updates“ verfügbare Aktualisierungen. Mit ihr fehlt der Punkt „Plugins > Plugin hinzufügen“, und Sie haben einen dokumentierten Update-Weg außerhalb des Backends.

Schritt 5: Debug-Einstellungen für den Produktivbetrieb

Auf einer Live-Website gehört WP_DEBUG auf false. Laut Dokumentation haben WP_DEBUG_LOG und WP_DEBUG_DISPLAY ohne aktives WP_DEBUG keine Wirkung. Brauchen Sie zur Fehlersuche kurzzeitig ein Protokoll, schalten Sie die Anzeige im Browser ab und schreiben in eine Datei außerhalb des Webverzeichnisses. WP_DEBUG_LOG akzeptiert dafür neben true auch einen Dateipfad:

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

Der Grund: Mit true landet das Log unter wp-content/debug.log. Im Labor war diese Datei ohne Anmeldung per HTTP mit Status 200 abrufbar. Sie enthält Serverpfade, Plugin-Namen und manchmal Inhalte aus Formularen. Mit dem Pfad außerhalb des Webverzeichnisses schrieb WordPress eine Testwarnung in die Datei, und die Startseite enthielt keine Fehlermeldung. Das Verzeichnis muss für den Webserver-Benutzer beschreibbar sein.

Nach der Fehlersuche setzen Sie WP_DEBUG wieder auf false. Die Dokumentation empfiehlt ausdrücklich, Log-Dateien danach zu löschen. Mehr zur Auswertung finden Sie in der Anleitung WordPress Debug-Modus aktivieren und Error-Logs analysieren.

Verifizieren: wp config get WP_DEBUG gibt auf der Live-Seite einen leeren Wert oder false aus, und curl -I https://ihre-domain.de/wp-content/debug.log liefert 404.

Schritt 6: HTTPS für Anmeldung und Backend erzwingen

FORCE_SSL_ADMIN sorgt laut Dokumentation dafür, dass Passwörter und Cookies bei Anmeldung und im Backend nie unverschlüsselt übertragen werden. Setzen Sie die Konstante erst, wenn die Website per HTTPS erreichbar ist:

wp config set FORCE_SSL_ADMIN true --raw

Im Labor leitete WordPress danach einen Aufruf von http://…/wp-login.php mit Status 302 auf die HTTPS-Adresse um. Läuft die Website hinter einem Reverse-Proxy oder CDN, das HTTPS beendet, muss WordPress das erkennen, sonst entsteht eine Weiterleitungsschleife. Die Anleitung WordPress nativ auf Ubuntu mit Apache und PHP-FPM zeigt die Einrichtung eines eigenen Servers mit Zertifikat.

Verifizieren: curl -I http://ihre-domain.de/wp-login.php antwortet mit einer Weiterleitung auf https://, und die Anmeldung funktioniert ohne Schleife.

Schritt 7: Zugriff auf die Datei einschränken

Normalerweise führt der Webserver wp-config.php als PHP aus und liefert nichts aus. Im Labor antwortete der Aufruf mit Status 200 und leerem Inhalt. Fällt der PHP-Handler aber durch einen Konfigurationsfehler aus, könnte der Server die Datei als Text ausliefern. Das Hardening-Kapitel empfiehlt deshalb eine Sperre in der .htaccess (Apache), ganz oben:

<Files "wp-config.php">
Require all denied
</Files>

Im Labor lieferte der Aufruf danach Status 403, die Website selbst lief unverändert. Zusätzlich empfiehlt die Dokumentation Dateirechte, bei denen nur Sie und der Webserver lesen dürfen, in der Regel 440 oder 400:

chmod 440 wp-config.php

Beachten Sie die Nebenwirkung: Eine schreibgeschützte Datei kann auch WP-CLI nicht mehr ändern. Im Labor scheiterte wp config shuffle-salts dann mit „Error: Could not process the 'wp-config.php' transformation. Reason: wp-config.php is not writable.“ Setzen Sie die Rechte für Änderungen kurz auf 640 und danach zurück. Welche Rechte Ihr Hoster erwartet, hängt davon ab, unter welchem Benutzer PHP läuft; fragen Sie im Zweifel nach, bevor Sie sich aussperren.

Verifizieren: curl -I https://ihre-domain.de/wp-config.php liefert 403, ls -l wp-config.php zeigt -r--r----- oder -r--------, und die Startseite lädt normal.

Typische Fehler

• Weiße Seite nach dem Bearbeiten: Meist ein Syntaxfehler durch typografische Anführungszeichen oder ein fehlendes Semikolon. Spielen Sie die Sicherung aus Schritt 1 zurück und ändern Sie die Datei mit wp config set.
• Konstante wirkt nicht: Sie steht unterhalb von „That's all, stop editing!“ oder ist doppelt definiert. PHP gibt bei doppelter Definition die Warnung „Constant … already defined“ aus, und der erste Wert gilt.
• „wp-config.php is not writable“: Folge der Rechte 440/400 aus Schritt 7. Rechte kurz auf 640 setzen, ändern, zurücksetzen.
• Plugins lassen sich nicht mehr aktualisieren: DISALLOW_FILE_MODS ist gesetzt. Entweder per WP-CLI aktualisieren oder die Konstante entfernen.
• Weiterleitungsschleife beim Login: FORCE_SSL_ADMIN hinter einem Proxy, der WordPress die HTTPS-Verbindung nicht mitteilt. Konstante vorübergehend entfernen und die Proxy-Konfiguration prüfen.

Häufige Fragen

Soll ich wp-config.php eine Ebene höher verschieben?

WordPress findet die Datei auch ein Verzeichnis oberhalb der Installation. Die offizielle Dokumentation hält den Nutzen aber für umstritten und warnt, dass ein unsauberes Verschieben neue Schwachstellen erzeugen kann. Sperre und Dateirechte aus Schritt 7 sind der einfachere Weg.

Muss ich die Salts regelmäßig wechseln?

Einen festen Rhythmus schreibt die Dokumentation nicht vor. Wechseln Sie sie anlassbezogen: nach einem Vorfall, bei Personalwechsel mit Admin-Zugang oder wenn die Datei unbeabsichtigt geteilt wurde.

Ersetzt das ein Sicherheits-Plugin?

Nein. Die Einstellungen reduzieren die Folgen eines gekaperten Kontos und eines Konfigurationsfehlers. Schutz vor Brute-Force-Angriffen, Zwei-Faktor-Anmeldung und aktuelle Plugins bleiben nötig.

Gilt die .htaccess-Regel auch für Nginx?

Nein, Nginx liest keine .htaccess. Dort muss die Sperre in der Serverkonfiguration stehen; das haben wir im Labor nicht getestet.

Testumfang

In unserem Test mit WordPress 7.1.2 unter Apache machte wp config shuffle-salts ein bestehendes Anmelde-Cookie tatsächlich ungültig. Auffällig war, dass sich Plugins per WP-CLI trotz Sperre weiterhin installieren ließen.

Nginx und den Betrieb hinter einem Reverse-Proxy haben wir nicht geprüft. Nutzen Sie eine solche Umgebung, testen Sie die Änderungen bitte zuerst auf einer Kopie Ihrer Website.

Fazit

Mit sechs Einstellungen ist wp-config.php deutlich robuster: neue Salts, gesperrter Datei-Editor, Debug nur ins private Log, HTTPS für die Anmeldung, Dateisperre und enge Rechte. DISALLOW_FILE_MODS lohnt sich nur mit einem verlässlichen Update-Weg außerhalb des Backends. Wenn Sie Updates, Backups und Firewall lieber in feste Hände geben, übernimmt das die WordPress-Wartung von Marcel Schönfelder.

Weiterführende Anleitungen und Quellen

• WordPress Debug-Modus aktivieren: Error-Logs analysieren und Fehler selbst beheben
• WordPress-Update fehlgeschlagen: weiße Seite, kritischer Fehler und Timeouts beheben
• WordPress-Updates per WP-CLI
• WordPress nativ auf Ubuntu mit Apache, MariaDB und PHP-FPM
• WordPress Advanced Administration: Editing wp-config.php
• WordPress Advanced Administration: Hardening WordPress
• WP-CLI: wp config shuffle-salts