wp-config.php: die Sicherheitseinstellungen, die wirklich zählen

Die Datei wp-config.php enthält die Zugangsdaten zur Datenbank und die Geheimnisse, mit denen deine Sitzungen signiert werden. Einige Konstanten darin stärken eine WordPress-Website deutlich, andere, falsch verstanden, schalten stillschweigend Schutzmechanismen ab. Hier erfährst du, was jede Einstellung tatsächlich bewirkt, überprüft im aktuellen Quellcode von WordPress, und welche Konfiguration für den Produktivbetrieb empfohlen ist.

Schlüssel und Salts: wozu sie wirklich dienen

Die Vorlagedatei wp-config-sample.php definiert acht Konstanten: AUTH_KEY, SECURE_AUTH_KEY, LOGGED_IN_KEY, NONCE_KEY und die vier zugehörigen Salts. Sie dienen dazu, die Anmeldecookies und die Sicherheitstokens (Nonces) von WordPress zu signieren. Ein Angreifer, der sie kennt, kann gültige Cookies erzeugen; eine Website, die die Beispielwerte behält, ist daher ernsthaft gefährdet.

Zwei verbreitete Irrtümer gilt es richtigzustellen:

• Sie dienen nicht zum Hashen der Passwörter der Benutzer. Seit WordPress 6.8 werden diese mit bcrypt gehasht, ohne Bezug zu diesen Konstanten;
• sie zu ändern, meldet alle ab: Der Kommentar in der Vorlagedatei sagt es ausdrücklich, alle Sitzungen werden ungültig.

Erzeuge sie mit dem offiziellen Dienst https://api.wordpress.org/secret-key/1.1/salt/, der acht Zeilen zum direkten Einfügen liefert.

Sollte man sie regelmäßig ändern?

Nein, nicht ohne Grund. Die Härtungsdokumentation von WordPress verweist selbst auf eine technische Analyse mit dem Titel „Warum du deine Salts nicht ändern solltest“. Ihr Argument: Viele Plugins nutzen diese Werte, um Daten zu verschlüsseln, zum Beispiel die Geheimnisse der Zwei-Faktor-Authentifizierung oder API-Schlüssel. Werden sie geändert, sind diese Daten nicht mehr lesbar. Ändere sie, wenn sie durchgesickert sein könnten: gehackte Website, offen zugängliches Backup, versehentlich veröffentlichte Datei, ehemaliger Dienstleister.

Den Datei-Editor abschalten: DISALLOW_FILE_EDIT

Standardmäßig kann ein Administrator den PHP-Code von Themes und Plugins im Dashboard bearbeiten. Wird ein Administratorkonto gestohlen, wird der Editor zu einem direkten Weg, Code einzuschleusen.

define( 'DISALLOW_FILE_EDIT', true );

Laut Härtungsanleitung von WordPress entspricht diese Zeile dem Entzug der Berechtigungen edit_themes, edit_plugins und edit_files. Dieselbe Anleitung nennt auch ihre Grenzen: Sie hindert einen Angreifer nicht daran, auf anderem Weg schädliche Dateien hochzuladen. Für fast alle Websites ist das eine Maßnahme ohne Nebenwirkungen, die du immer anwenden solltest.

DISALLOW_FILE_MODS: stärker, aber riskanter

DISALLOW_FILE_MODS geht weiter: Es blockiert auch die Installation und Aktualisierung von Plugins und Themes über das Dashboard. Der WordPress-Code zeigt aber eine weniger bekannte Wirkung: Die Funktion wp_is_file_mod_allowed() gibt für alle Kontexte false zurück, auch für den der automatischen Updates. Mit dieser Konstante installieren sich die kleineren Sicherheitsupdates des Core nicht mehr von selbst.

Verwende sie nur bei Websites, deren Updates auf anderem Weg ausgerollt werden (Git, Deployment-Werkzeug, Hoster), mit einem Prozess, der die Patches tatsächlich nachverfolgt.

FORCE_SSL_ADMIN: oft schon aktiv

FORCE_SSL_ADMIN erzwingt HTTPS für die Anmeldung und den Adminbereich, damit Passwörter und Cookies nie im Klartext übertragen werden. Die Datei default-constants.php zeigt, dass WordPress sie automatisch auf true setzt, wenn du sie nicht definierst und die Adresse der Website mit https beginnt. Sie ausdrücklich zu definieren, bleibt sinnvoll, um die Entscheidung zu dokumentieren oder wenn die gespeicherte Adresse noch http lautet. Die alte Konstante FORCE_SSL_LOGIN ist seit WordPress 4.0 veraltet.

WP_DEBUG im Produktivbetrieb

Debugging ist in der Entwicklung unverzichtbar und im Produktivbetrieb aus zwei Gründen gefährlich.

• Die Anzeige der Fehler (WP_DEBUG_DISPLAY, standardmäßig true, wenn WP_DEBUG aktiv ist) verrät jedem Besucher Dateipfade, Abfragen und Plugin-Namen.
• Das Log (WP_DEBUG_LOG auf true) wird standardmäßig in wp-content/debug.log geschrieben, eine Adresse, die alle Bots kennen. Es kann sensible Daten enthalten: 2024 beruhte eine Lücke in LiteSpeed Cache (CVE-2024-44000) genau auf Sitzungscookies, die in diese Datei geschrieben wurden.

Belasse WP_DEBUG im Produktivbetrieb auf false. Für eine gezielte Diagnose akzeptiert WP_DEBUG_LOG seit WordPress 5.1 einen Pfad: Lege das Log außerhalb des Web-Stammverzeichnisses ab und schalte die Anzeige ab.

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_DISPLAY', false );
define( 'WP_DEBUG_LOG', '/home/konto/logs/wp-debug.log' ); // außerhalb des Web-Roots

Entferne diese Zeilen und die Logdatei, sobald das Problem gelöst ist.

Konstante	Empfohlener Wert im Produktivbetrieb	Überprüfte Wirkung	Falle
Schlüssel und Salts	Eindeutige, generierte Werte	Signieren Cookies und Nonces	Eine Änderung meldet alle ab und kann verschlüsselte Daten unbrauchbar machen
DISALLOW_FILE_EDIT	true	Entfernt den Datei-Editor	Keine für die meisten Websites
DISALLOW_FILE_MODS	Nur mit externem Deployment	Blockiert Installationen und Updates	Schaltet auch die automatischen Updates ab
FORCE_SSL_ADMIN	true	Adminbereich über HTTPS	Standardmäßig bereits true, wenn die Adresse der Website mit https beginnt
WP_DEBUG	false	Deaktiviert den Debug-Modus	Standard-Log öffentlich in wp-content
WP_AUTO_UPDATE_CORE	'minor' (Standard) oder true	Steuert die automatischen Core-Updates	false deaktiviert auch die Sicherheitsupdates
WP_ENVIRONMENT_TYPE	'production'	Gibt die Art der Umgebung an	Unbekannter Wert: standardmäßig production

Wo wp-config.php liegen sollte

Eine Ebene über dem Stammverzeichnis

Die Datei wp-load.php sucht wp-config.php im WordPress-Verzeichnis und, wenn sie sie dort nicht findet, eine Ebene darüber, sofern dieses übergeordnete Verzeichnis nicht selbst eine wp-settings.php enthält (um zwei verschachtelte Installationen nicht zu verwechseln). Liegt die Datei außerhalb des Web-Stammverzeichnisses, kann sie garantiert nie über eine einfache Anfrage ausgeliefert werden.

Die Härtungsanleitung von WordPress räumt ein, dass der Nutzen umstritten ist: Solange PHP funktioniert, wird die Datei nie angezeigt, denn sie wird ausgeführt. Das Verschieben schützt vor allem für den Fall, dass der Server PHP nicht mehr ausführt und die Dateien als Klartext ausliefert. Auf einem Shared Hosting, bei dem WordPress direkt in public_html installiert ist, ist das einfach und risikolos; in einem Unterordner solltest du die Struktur prüfen.

Berechtigungen und Sperre auf Serverebene

• Berechtigungen: Die Härtungsanleitung empfiehlt, dass nur du und der Webserver die Datei lesen können, was in der Regel 400 oder 440 entspricht. Je nach Hoster kann 600 oder 640 nötig sein.
• Unter Apache oder LiteSpeed blockiert ein Block <Files "wp-config.php"> mit Require all denied in der .htaccess direkte Anfragen.
• Lass niemals Kopien herumliegen: wp-config.php.bak, wp-config.old oder wp-config.php~ werden von PHP nicht ausgeführt und würden als Klartext ausgeliefert, samt Passwörtern.

Mit WP Masquerade

WP Masquerade verändert niemals wp-config.php oder die Core-Dateien. Die Bot-Fallen der kostenlosen Version zählen Anfragen nach sensiblen Dateien wie .bak-Backups und zeigen so, wonach Bots auf deiner Website suchen. In der Pro-Version verschlüsselt die Zwei-Faktor-Authentifizierung die Geheimnisse der Benutzer mit den Schlüsseln der Website: Die Anleitung weist darauf hin, dass man sich nach einer Änderung der Schlüssel mit einem Backup-Code anmelden und die Zwei-Faktor-Authentifizierung neu einrichten muss. Die Integritätsprüfung vergleicht die Core-Dateien mit den offiziellen Prüfsummen und schließt dabei wp-config.php, die für jede Website individuell ist, bewusst aus.

Point SECU #6 : 3 Mythes sur le fichier wp-config.phpMit dem Klick wird das Video von youtube-nocookie.com (YouTube, Google) geladen. Vor deinem Klick wird nichts geladen.

Déplacer le fichier wp-config.php [WordPress Sécurité]Mit dem Klick wird das Video von youtube-nocookie.com (YouTube, Google) geladen. Vor deinem Klick wird nichts geladen.

Lies auch: WordPress-Fehler verstehen und die Website debuggen.

Lies auch: WordPress Multisite installieren und ein Netzwerk aus Websites erstellen.

Quellen

• WordPress Developer Resources: Editing wp-config.php (öffnet in neuem Tab)
• WordPress Developer Resources: Hardening WordPress (öffnet in neuem Tab)
• Make WordPress Core: WordPress 6.8 will use bcrypt for password hashing (öffnet in neuem Tab)
• Offizieller Schlüsselgenerator: api.wordpress.org/secret-key/1.1/salt/ (öffnet in neuem Tab)

Weitere herangezogene Quellen: offizielle Herstellerseiten und Veröffentlichungen von Sicherheitsforschern.