wp-config.php in WordPress absichern

Die Datei wp-config.php im Stammverzeichnis jeder WordPress-Installation enthält die Datenbank-Zugangsdaten (Host, Name, Benutzer, Passwort), die geheimen Security-Keys und Salts sowie zentrale Konfigurationskonstanten. Gelangt diese Datei in falsche Hände, ist praktisch die gesamte Website kompromittiert. Sie ist deshalb die wichtigste einzelne Datei, die es abzusichern gilt. Diese Anleitung zeigt vier Härtungsmaßnahmen: frische Security-Keys erzeugen, restriktive Dateiberechtigungen setzen, den direkten HTTP-Zugriff auf die Datei sperren und schützende Konstanten wie DISALLOW_FILE_EDIT ergänzen. Optional lässt sich die Datei eine Ebene über dem Webroot verschieben. Alle Schritte lassen sich in etwa 20 Minuten über SFTP/SSH und die .htaccess bzw. nginx-Konfiguration umsetzen.

Schritt 1: Security-Keys und Salts erneuern

WordPress nutzt acht geheime Zeichenketten (AUTH_KEY, SECURE_AUTH_KEY, LOGGED_IN_KEY, NONCE_KEY und die vier zugehörigen _SALT-Werte), um Login-Cookies und Nonces zu verschlüsseln. Waren diese Werte je öffentlich (z. B. in einem Backup, das im Web lag) oder wurden sie nie geändert, sollten Sie sie erneuern. WordPress stellt dafür einen offiziellen Generator bereit:

# Aktuelle Zufallswerte abrufen:
https://api.wordpress.org/secret-key/1.1/salt/

Ersetzen Sie in der wp-config.php den vorhandenen Block durch die frisch generierten Werte:

define( 'AUTH_KEY',         'hier-langer-zufallswert' );
define( 'SECURE_AUTH_KEY',  'hier-langer-zufallswert' );
define( 'LOGGED_IN_KEY',    'hier-langer-zufallswert' );
define( 'NONCE_KEY',        'hier-langer-zufallswert' );
define( 'AUTH_SALT',        'hier-langer-zufallswert' );
define( 'SECURE_AUTH_SALT', 'hier-langer-zufallswert' );
define( 'LOGGED_IN_SALT',   'hier-langer-zufallswert' );
define( 'NONCE_SALT',       'hier-langer-zufallswert' );

Nach dem Speichern werden alle angemeldeten Nutzer ausgeloggt – das ist gewollt und ein wirksames Mittel, um gestohlene Sitzungen zu invalidieren.

Schritt 2: Dateiberechtigungen setzen

Die wp-config.php sollte für den Webserver lesbar, aber für andere Benutzer nicht zugänglich sein. Empfohlen ist 600 (nur der Eigentümer darf lesen/schreiben) oder 640, falls die Webserver-Gruppe Lesezugriff benötigt:

# Nur Eigentümer liest und schreibt
chmod 600 wp-config.php

# Alternativ, wenn die Webserver-Gruppe lesen muss
chmod 640 wp-config.php

Setzen Sie niemals 777 oder 666 – damit kann jeder Benutzer auf dem System die Datei lesen und die Datenbank-Zugangsdaten auslesen.

Schritt 3: Direkten HTTP-Zugriff sperren

Normalerweise wird wp-config.php als PHP ausgeführt und liefert keine Ausgabe. Fällt die PHP-Verarbeitung jedoch aus (Fehlkonfiguration, Server-Umzug), könnte der Klartext-Inhalt ausgeliefert werden. Sperren Sie den direkten Zugriff zusätzlich auf Webserver-Ebene.

Apache (.htaccess)

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

nginx

location = /wp-config.php {
    deny all;
    return 403;
}

Schritt 4: Härtungskonstanten ergänzen

Ergänzen Sie in der wp-config.php oberhalb der Zeile /* That's all, stop editing! */ folgende Konstanten:

// Datei-Editor im Adminbereich abschalten (verhindert das Bearbeiten
// von Theme- und Plugin-Code über wp-admin)
define( 'DISALLOW_FILE_EDIT', true );

// Optional: Installation/Updates von Plugins und Themes über das
// Dashboard komplett unterbinden (strengste Variante)
// define( 'DISALLOW_FILE_MODS', true );

// Debug-Ausgaben im Produktivbetrieb abschalten
define( 'WP_DEBUG', false );
define( 'WP_DEBUG_DISPLAY', false );

// Nur noch verschlüsselte Verbindungen im Adminbereich erzwingen
define( 'FORCE_SSL_ADMIN', true );

// Automatische Kern-Updates auf Sicherheits-Releases beschränken
define( 'WP_AUTO_UPDATE_CORE', 'minor' );

DISALLOW_FILE_EDIT ist besonders wichtig: Ohne diese Konstante kann ein Angreifer, der einen Admin-Account übernimmt, direkt über Design » Theme-Editor beliebigen PHP-Code ausführen.

Optional: wp-config.php außerhalb des Webroots verschieben

WordPress sucht die wp-config.php automatisch auch eine Verzeichnisebene oberhalb des Webroots. Liegt Ihr WordPress unter /var/www/html/, können Sie die Datei nach /var/www/wp-config.php verschieben. So liegt sie außerhalb des über HTTP erreichbaren Bereichs.

Achtung: Das funktioniert zuverlässig nur bei klassischen Single-Site-Setups mit eigenem Webroot. Bei Shared Hosting, wo mehrere Seiten dieselbe übergeordnete Ebene teilen, kann das Verschieben zu Konflikten führen. Prüfen Sie im Zweifel mit Ihrem Hoster.

Wie prüfe ich, ob die Absicherung greift?

1. Rufen Sie https://ihre-domain.de/wp-config.php im Browser auf. Erwartet: eine leere Seite (PHP-Ausführung) oder 403 Forbidden (Zugriffssperre) – niemals lesbarer PHP-Quelltext.
2. Per Terminal:

   curl -s -o /dev/null -w "%{http_code}\n" https://ihre-domain.de/wp-config.php
   # Erwartet: 403 (bei aktiver Sperre) oder 200 mit leerem Body

3. Berechtigungen kontrollieren:

   ls -l wp-config.php
   # Erwartet: -rw------- (600) oder -rw-r----- (640)

4. Im Adminbereich prüfen, dass unter Design und Plugins kein Editor mehr erscheint (Wirkung von DISALLOW_FILE_EDIT).

Häufige Fehler

• Zu strenge Berechtigungen: Bei manchen Hostern läuft PHP nicht als Datei-Eigentümer. Dann kann 600 zu einem 500-Fehler führen – in dem Fall 640 oder 644 verwenden.
• Keys ohne Backup ersetzt: Sichern Sie die Datei vor Änderungen. Ein Tippfehler in den Konstanten legt die Seite lahm.
• DISALLOW_FILE_MODS zu früh: Diese Konstante blockiert auch reguläre Plugin-/Theme-Updates über das Dashboard. Nur setzen, wenn Updates ausschließlich per Deployment/WP-CLI laufen.
• Datei verschoben, aber Pfad falsch: Beim Verschieben außerhalb des Webroots keinen eigenen require-Loader basteln, der einen absoluten Serverpfad offenlegt.

Häufige Fragen (FAQ)

Welche Dateiberechtigung sollte die wp-config.php haben?

Empfohlen ist 600 (nur der Eigentümer darf lesen und schreiben). Läuft PHP auf Ihrem Hoster nicht als Datei-Eigentümer, sondern über die Gruppe, verwenden Sie 640. Setzen Sie niemals 777 oder 666, weil dann jeder Benutzer auf dem Server die Datenbank-Zugangsdaten auslesen kann.

Was passiert, wenn ich die Security-Keys in der wp-config.php ändere?

Alle angemeldeten Benutzer werden ausgeloggt und müssen sich neu anmelden. Das ist gewollt und ein wirksames Mittel, um gestohlene Sitzungscookies zu invalidieren. Die Inhalte der Website bleiben unverändert. Erzeugen Sie frische Werte über den offiziellen WordPress-Secret-Key-Generator.

Wofür ist die Konstante DISALLOW_FILE_EDIT gut?

DISALLOW_FILE_EDIT deaktiviert den Theme- und Plugin-Editor im WordPress-Adminbereich. Ohne diese Konstante kann ein Angreifer, der einen Admin-Account übernimmt, über Design » Theme-Editor direkt beliebigen PHP-Code ausführen. Die Konstante ist damit eine der wichtigsten Härtungsmaßnahmen.

Sollte ich die wp-config.php außerhalb des Webroots verschieben?

WordPress sucht die wp-config.php automatisch auch eine Verzeichnisebene oberhalb des Webroots. Bei klassischen Single-Site-Setups mit eigenem Webroot erhöht das Verschieben die Sicherheit. Bei Shared Hosting, wo mehrere Seiten dieselbe übergeordnete Ebene teilen, kann es jedoch zu Konflikten führen – im Zweifel mit dem Hoster abstimmen.

Wie hilft InspectWP bei der wp-config.php?

InspectWP prüft beim Crawl unter anderem, ob sensible Dateien wie wp-config.php oder ein wp-config.php.bak-Backup öffentlich abrufbar sind, ob der Adminbereich per HTTPS erzwungen wird und ob Debug-Ausgaben nach außen dringen. Entsprechende Funde werden im Report als Sicherheitsrisiko markiert.