--- title: "wp-config.php härten: Salts, Dateibearbeitung und Debug-Einstellungen" date: 2026-09-30T21:16:46+02:00 modified: 2026-10-14T01:17:45+02:00 category: wordpress type: how_to author: Marcel Schönfelder canonical: https://s-edv.com/anleitungen/wordpress-wp-config-haerten-salts-dateibearbeitung-debug keywords: - WordPress - Sicherheit - wp-config.php - WP-CLI - Härtung reading_time: 9 --- # 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. **Kurzfassung:** Sichern Sie `wp-config.php`, erneuern Sie die Schlüssel mit `wp config shuffle-salts` und setzen Sie `DISALLOW_FILE_EDIT` auf `true`. Auf Produktivseiten gehört `WP_DEBUG` auf `false`; zur Fehlersuche schreiben Sie das Log mit `WP_DEBUG_LOG` in eine Datei außerhalb des Webverzeichnisses. Aktivieren Sie `FORCE_SSL_ADMIN`, sobald HTTPS läuft, sperren Sie die Datei per `.htaccess` und setzen Sie die Rechte auf 440 oder 400. `DISALLOW_FILE_MODS` ist nur sinnvoll, wenn Updates außerhalb des Backends laufen. ## 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: ```bash $ 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](https://s-edv.com/anleitungen/wordpress-update-fehler-beheben-weisse-seite-kritischer-fehler). > **Prüfen:** 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. ```bash $ 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](https://api.wordpress.org/secret-key/1.1/salt/) 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. > **Prüfen:** 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: ```bash $ wp config set DISALLOW_FILE_EDIT true --raw ``` Das ergibt in der Datei diese Zeile: ```php 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. > **Prüfen:** 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`. ```php 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](https://wordpressupdate.de/?utm_source=s-edv.com&utm_medium=artikel&utm_campaign=31) übernimmt Updates von WordPress, Plugins und Themes, wöchentliche Backups auf externen Speicher sowie Einrichtung und Wartung einer Firewall. > **Prüfen:** 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: ```php 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](https://s-edv.com/anleitungen/wordpress-debug-modus-error-logs-fehler-beheben). > **Prüfen:** `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: ```bash $ 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](https://s-edv.com/anleitungen/wordpress-nativ-ubuntu-lamp-apache-mariadb-php-fpm) zeigt die Einrichtung eines eigenen Servers mit Zertifikat. > **Prüfen:** `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: Datei: `wp-config.php` ```apache Require all denied ``` 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: ```bash $ 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. > **Prüfen:** `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. ## 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](https://wordpressupdate.de/?utm_source=s-edv.com&utm_medium=fazit&utm_campaign=31). ## Weiterführende Anleitungen und Quellen - [WordPress Debug-Modus aktivieren: Error-Logs analysieren und Fehler selbst beheben](https://s-edv.com/anleitungen/wordpress-debug-modus-error-logs-fehler-beheben) - [WordPress-Update fehlgeschlagen: weiße Seite, kritischer Fehler und Timeouts beheben](https://s-edv.com/anleitungen/wordpress-update-fehler-beheben-weisse-seite-kritischer-fehler) - [WordPress-Updates per WP-CLI](https://s-edv.com/anleitungen/wordpress-updates-wp-cli-core-plugins-themes) - [WordPress nativ auf Ubuntu mit Apache, MariaDB und PHP-FPM](https://s-edv.com/anleitungen/wordpress-nativ-ubuntu-lamp-apache-mariadb-php-fpm) - [WordPress Advanced Administration: Editing wp-config.php](https://developer.wordpress.org/advanced-administration/wordpress/wp-config/) - [WordPress Advanced Administration: Hardening WordPress](https://developer.wordpress.org/advanced-administration/security/hardening/) - [WP-CLI: wp config shuffle-salts](https://developer.wordpress.org/cli/commands/config/shuffle-salts/)