wp-config.php in WordPress: erklärt und abgesichert

Die wp-config.php ist die Konfigurationsdatei von WordPress. Sie enthält, was WordPress wissen muss, bevor es die Datenbank überhaupt erreicht: Name, Benutzer, Passwort und Host der Datenbank, das Tabellenpräfix, acht Sicherheitsschlüssel und alle Schalter, die als PHP-Konstante gesetzt werden. Bei der Installation entsteht sie aus der mitgelieferten wp-config-sample.php. Danach fasst WordPress sie nicht mehr an, Updates überschreiben sie nicht. Was darin steht, bleibt, bis jemand es ändert.

Wer die wp-config.php lesen kann, hat die Datenbank. Das Datenbankpasswort steht dort im Klartext, weil PHP es zur Laufzeit braucht. Deshalb ist die Datei das Erste, was ein Angreifer nach einem Einbruch sucht, und das Erste, was nach einem Befall geändert werden muss.

Wo die Datei liegt#

Steht die Datei mit falschen Rechten, im Git oder als Kopie im Webverzeichnis? Der Sicherheits-Check für 290 € prüft das zusammen mit Plugins, Headern und Zugängen und liefert einen Bericht nach Dringlichkeit.

Normalerweise im Hauptverzeichnis der Installation, neben wp-settings.php und den Ordnern wp-admin, wp-content und wp-includes. Sie darf aber auch eine Ebene darüber liegen, außerhalb des Webverzeichnisses. Der Quelltext von wp-load.php sucht sie zuerst im Hauptverzeichnis und dann eine Ebene höher, dort aber nur, wenn daneben keine wp-settings.php liegt, also keine zweite WordPress-Installation. Die WordPress-Dokumentation zur Härtung nennt das ausdrücklich als Möglichkeit.

Ob sich der Umzug lohnt, hängt vom Hosting ab. Liegt das Webverzeichnis bei deinem Hoster in einem Unterordner wie public_html, ist eine Ebene darüber oft nicht mehr per Browser erreichbar, und die Datei ist dort besser aufgehoben. Liegt WordPress direkt im obersten Verzeichnis deines Kontos, bringt es nichts. Wo die Datei gerade liegt, zeigt wp config path.

Was drinsteht, Block für Block#

Datenbank. Vier Konstanten verbinden WordPress mit MySQL oder MariaDB: DB_NAME, DB_USER, DB_PASSWORD, DB_HOST. Dazu DB_CHARSET, in der aktuellen Vorlage utf8mb4, und DB_COLLATE, meist leer. Stimmt eine der ersten vier nicht, erscheint „Fehler beim Aufbau einer Datenbankverbindung“; wie man das eingrenzt, steht in Fehler beim Aufbau einer Datenbankverbindung beheben.

Sicherheitsschlüssel. Acht Zeilen: AUTH_KEY, SECURE_AUTH_KEY, LOGGED_IN_KEY, NONCE_KEY und die vier passenden …_SALT. WordPress signiert damit Anmelde-Cookies und Formular-Schlüssel. Laut Kommentar in der Vorlage lassen sie sich jederzeit ändern, und dann müssen sich alle Benutzer neu anmelden. Genau das ist nach einem Einbruch oder nach dem Abgang eines Mitarbeiters mit Administratorrechten gewollt. Mit WP-CLI ist das ein Befehl:

wp config shuffle-salts

Tabellenpräfix. $table_prefix ist keine Konstante, sondern eine Variable, ab Werk 'wp_'. Erlaubt sind laut Vorlage nur Ziffern, Buchstaben und Unterstriche. Wichtig ist der Satz danach in der Vorlage: Wer das Präfix nach der Installation ändert, ohne die Tabellen mitzuziehen, bringt WordPress dazu, sich für nicht installiert zu halten. Ein anderes Präfix als wp_ zu wählen schützt übrigens kaum; es hilft nur gegen sehr einfache automatische Angriffe, die mit festen Tabellennamen arbeiten.

Die Zeile „stop editing“. Eigene Einstellungen gehören zwischen „Add any custom values between this line and the "stop editing" line.“ und „That's all, stop editing! Happy publishing.“. Darunter wird ABSPATH gesetzt und wp-settings.php geladen. Was nach dieser Zeile steht, kommt zu spät: WordPress hat seine Voreinstellungen dann schon festgelegt.

Die Konstanten, die man kennen sollte#

Die WordPress-Dokumentation listet Dutzende Konstanten. Für eine Firmenseite reichen diese, sortiert nach ihrer Wirkung auf Sicherheit und Betrieb.

Drei davon brauchen einen Satz mehr.

DISALLOW_FILE_EDIT ist die wichtigste Zeile, die in fast keiner Installation steht. Ohne sie kann jeder, der ein Administratorkonto übernimmt, im Backend PHP-Code in ein Plugin schreiben und damit beliebige Befehle auf dem Server ausführen. Die Dokumentation weist darauf hin, dass manche Plugins sich daran stören; das ist selten und lässt sich in einer Minute feststellen. DISALLOW_FILE_MODS schließt den Editor gleich mit ein, sperrt aber auch die Update-Knöpfe. Das passt zu einer Wartung über WP-CLI, für eine Seite, die der Betreiber selbst im Backend aktualisiert, ist es falsch.

WP_ENVIRONMENT_TYPE ist auf einer Staging-Kopie nützlich: Plugins können damit erkennen, dass sie keine echten Mails verschicken oder Zahlungen auslösen sollen. Ein ungültiger Wert fällt laut Dokumentation auf production zurück.

DISABLE_WP_CRON ist kein Leistungstrick, sondern eine Umstellung. WordPress führt geplante Aufgaben (Veröffentlichung zu einem Zeitpunkt, Sicherungen, Update-Prüfungen) normalerweise beim Seitenaufruf aus. Wer das abschaltet, muss beim Hoster einen Cronjob anlegen, der zum Beispiel alle fünf Minuten wp cron event run --due-now aufruft. Fehlt der, bleiben geplante Beiträge und automatische Updates einfach liegen.

Ändern ohne Editor: WP-CLI#

Die meisten Fehler in der wp-config.php entstehen beim Bearbeiten. WP-CLI schreibt die Zeilen selbst, im richtigen Format:

wp config list                                   # alle Konstanten und Variablen
wp config get table_prefix                       # einen Wert lesen
wp config set DISALLOW_FILE_EDIT true --raw      # Konstante setzen
wp config set WP_ENVIRONMENT_TYPE staging        # Zeichenkette setzen
wp config shuffle-salts                          # neue Schlüssel, alle neu anmelden
wp config path                                   # wo die Datei liegt

--raw sorgt dafür, dass true als Wahrheitswert und nicht als Zeichenkette 'true' geschrieben wird. Bei wp config list Vorsicht: Die Ausgabe enthält Datenbankpasswort und Schlüssel. Nicht in ein Ticket, einen Chat oder eine KI kopieren.

Wenn du die Datei doch von Hand bearbeitest#

Drei Fehler legen die Seite lahm, und alle drei passieren vor dem Fehlerschutz von WordPress, weil die wp-config.php gelesen wird, bevor dieser geladen ist. Das Ergebnis ist eine weiße Seite statt einer Fehlermeldung, siehe WordPress zeigt eine weiße Seite.

• Typografische Anführungszeichen. Wer eine Zeile aus einer Webseite, einem Textverarbeitungsprogramm oder einer Mail kopiert, bekommt oft „…“ oder ‚…‘ statt ' und ". PHP kennt sie nicht und bricht ab.
• Fehlendes Semikolon oder fehlende Klammer am Zeilenende.
• Zeile unterhalb von „stop editing“. Bricht nichts ab, wirkt aber nicht.

Nach jeder Handänderung die Syntax prüfen, ohne die Datei auszuführen:

php -l wp-config.php

„No syntax errors detected“ heißt, die Datei ist lesbar, nicht, dass die Werte stimmen. Eine Kopie der alten Fassung gehört vorher außerhalb des Webverzeichnisses abgelegt, nicht als wp-config.php.bak daneben.

Die Datei absichern#

Dateirechte. Die Härtungsanleitung von WordPress empfiehlt, dass nur du und der Webserver die Datei lesen dürfen, „in der Regel 400 oder 440“. Prüfen und setzen per SSH:

stat -c '%a %U:%G' wp-config.php
chmod 440 wp-config.php

Welcher der beiden Werte passt, hängt davon ab, unter welchem Benutzer PHP bei deinem Hoster läuft. Ist es dein eigener Benutzer, reicht 400. Gehört die Datei einem anderen Benutzer als PHP, braucht die Gruppe Leserechte, also 440. Danach die Seite aufrufen; kommt „Fehler beim Aufbau einer Datenbankverbindung“ oder eine weiße Seite, kann PHP die Datei nicht mehr lesen, und der Hoster muss sagen, welcher Wert bei ihm gilt.

Zugriff per Webserver sperren. PHP-Dateien werden normalerweise ausgeführt und nicht als Text ausgeliefert. Das gilt aber nur, solange PHP am Webserver richtig eingebunden ist. Auf Apache steht laut Härtungsanleitung ganz oben in der .htaccess:

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

Auf nginx erledigt das ein location = /wp-config.php { deny all; } im Serverblock.

Kopien entfernen. Das eigentliche Risiko sind selten die Rechte, sondern Kopien mit anderer Endung: wp-config.php.bak, wp-config.php.old, wp-config.php~ oder wp-config.php.save, die Editoren und Hilfsprogramme anlegen. Solche Dateien führt der Webserver nicht als PHP aus, sondern liefert sie als Text aus, mit Datenbankpasswort. Suchen:

find . -maxdepth 2 -name 'wp-config*' ! -name 'wp-config.php' ! -name 'wp-config-sample.php'

Nicht ins Git, nicht in öffentliche Sicherungen. Wer seine Seite in einem Repository verwaltet, trägt wp-config.php in die .gitignore ein und legt die Zugangsdaten als Umgebungsvariablen oder in einer zweiten, nicht versionierten Datei ab. Sicherungs-Plugins, die ihre Archive unter wp-content/ ablegen, gehören ebenfalls auf die Liste: Ein Archiv mit wp-config.php im Webverzeichnis ist dieselbe Lücke wie eine .bak-Datei. Wo Sicherungen hingehören, steht in WordPress-Backup.

Die übrigen Maßnahmen zur Absicherung, nach Wirkung sortiert und je mit Befehl, stehen in WordPress-Sicherheit prüfen.

Was nicht hilft#

Die Datei umbenennen. WordPress sucht genau wp-config.php. Ein anderer Name heißt: WordPress startet die Installation neu.

Die Konfiguration mit einem Plugin „verstecken“. Ein Plugin läuft erst, nachdem die Datei gelesen wurde, und kann an ihren Rechten oder ihrem Ort nichts ändern, was du nicht mit zwei Befehlen selbst machst.

Die Sicherheitsschlüssel aus einer Anleitung kopieren. Schlüssel, die schon einmal irgendwo veröffentlicht wurden, sind keine. wp config shuffle-salts erzeugt neue.

WP_DEBUG dauerhaft an lassen. Auch mit WP_DEBUG_DISPLAY auf false wächst die debug.log und verrät Pfade und Versionen, wenn sie im Webverzeichnis liegt.

Wenn du es nicht selbst machen willst#

In eigener Sache: cyberscale bin ich, Stefan Haun aus Tirol. Rechte, Kopien, Debug-Einstellungen und die Konstanten der wp-config.php sind Teil des Sicherheits-Checks für 290 €, mit Bericht nach Dringlichkeit. Wer danach will, dass jemand die Seite laufend im Blick hat, Updates eingespielt und Sicherungen geprüft, bekommt das mit der WordPress-Wartung für 49 € im Monat. Steht die Seite nach einer Änderung an der Datei, hilft die WordPress-Soforthilfe, und welche Meldung was bedeutet, steht in WordPress-Fehlermeldungen.

Häufige Fragen#

Stand 13.10.2026. WordPress-Quelltext (wp-load.php, wp-config-sample.php, default-constants.php), WordPress-Dokumentation zu wp-config.php und zur Härtung sowie die WP-CLI-Dokumentation an diesem Tag gelesen.