wp-config.phpenthält Datenbankzugänge, Authentifizierungsschlüssel und weitere umgebungsspezifische Einstellungen. PHP führt die Datei normalerweise aus, sodass ihr Quelltext bei einem direkten Aufruf nicht sichtbar wird. Eine Apache-Regel kann den HTTP-Zugriff dennoch als zusätzliche Schutzschicht ausdrücklich sperren.
Diese Sperre ist nur ein Baustein. Ebenso wichtig sind passende Dateirechte, ein sicherer Speicherort und die Entfernung von Kopien wie wp-config.php.bak.
Inhaltsverzeichnis
Was die .htaccess-Sperre leistet
Eine Dateiregel in .htaccessweist Apache an, externe Anfragen an den exakten Namen wp-config.phpabzulehnen. WordPress selbst kann die Datei weiterhin lokal über PHP laden. Die Regel schützt also den HTTP-Zugriff, nicht den Zugriff eines kompromittierten Serverkontos oder eines lokalen Prozesses.
Die Wirkung gilt nur dort, wo Apache die Datei auswertet. Bei Nginx ist eine entsprechende Serverregel erforderlich. Manche verwalteten Hosting-Plattformen sperren die Datei bereits zentral.
Ein realistisches Risiko
Der Aufruf von wp-config.phpliefert erwartungsgemäß keine Daten. Im selben Verzeichnis liegt jedoch eine Sicherung namens wp-config.php.bak, die der Webserver als Textdatei ausliefert. Eine Regel für den exakten Originalnamen erfasst diese Kopie nicht.
Die richtige Reaktion ist, die Sicherung aus dem Webroot zu entfernen und mögliche offengelegte Zugangsdaten zu ersetzen. Ein immer breiteres Dateimuster wäre kein verlässlicher Ersatz für saubere Dateiverwaltung.
Warum mehrere Schutzschichten nötig sind
Ein Serverfehler oder eine falsche PHP-Zuordnung kann Quellcode unter Umständen offenlegen. Die explizite HTTP-Sperre reduziert dieses Risiko. Restriktive Dateirechte begrenzen zugleich, welche lokalen Benutzer und Prozesse die Konfiguration lesen dürfen.
WordPress kann wp-config.phpin üblichen Installationen eine Ebene oberhalb des Webroots finden. Diese Anordnung kann sinnvoll sein, muss aber zur Hosting- und Deployment-Architektur passen. Sie schützt nicht, wenn ein anderer Virtual Host das übergeordnete Verzeichnis öffentlich ausliefert.
Der sichere Einstieg
- Ermitteln Sie, welche
wp-config.phpdie aktive Installation verwendet. - Suchen Sie im öffentlichen Dateibaum nach Sicherungs- und Editor-Kopien und entfernen Sie diese.
- Prüfen Sie Eigentümer und Dateirechte; vermeiden Sie unnötig breite Schreib- oder Leserechte.
- Sichern Sie die aktive
.htaccessaußerhalb des Webroots. - Ergänzen Sie die Sperre außerhalb der von WordPress verwalteten Markierungen und testen Sie danach Frontend sowie Backend.
Halten Sie vor dem Speichern SFTP- oder Hosting-Panel-Zugang bereit. Eine für den Server unzulässige Direktive kann einen Fehler 500 verursachen.
Die technische Umsetzung
Unter Apache 2.4 kann eine eng gefasste Regel so aussehen:
<Files "wp-config.php">
Require all denied
</Files>Ältere Beispiele verwenden die Apache-2.2-Syntax mit Orderund Deny. Mischen Sie beide Varianten nicht ohne Prüfung. Entscheidend sind die installierte Apache-Version und die vom Hoster erlaubten Override-Klassen.
Rufen Sie die Datei über HTTPS sowie über jeden alternativen öffentlichen Host auf. Prüfen Sie anschließend eine datenbankgestützte Seite, Anmeldung, Cron und REST API. So erkennen Sie, ob lediglich externe Anfragen blockiert werden oder die Regel versehentlich den normalen WordPress-Start beeinträchtigt.
Wurden Zugangsdaten tatsächlich offengelegt, genügt die Sperre nicht: Ändern Sie Datenbankpasswort und betroffene Schlüssel, prüfen Sie Logs und aktualisieren Sie die Konfiguration kontrolliert.
Risiken, Backup und Rollback
Eine falsche Autorisierungsdirektive oder ein Syntaxfehler kann die gesamte Website unzugänglich machen. Zu breite Muster können andere notwendige PHP-Dateien erfassen. Ein Schutz nur für den Originalnamen übersieht dagegen öffentlich abgelegte Kopien.
Stellen Sie bei einem Fehler die vorherige .htaccessüber den unabhängigen Dateizugriff wieder her. Bewahren Sie die Sicherung nicht im öffentlich erreichbaren Verzeichnis auf. Testen Sie nach dem Rollback sowohl WordPress als auch den direkten Aufruf der Konfigurationsdatei.
Wie AIOWS unterstützt:
Wie AIOWS Htaccess Editor hilft
AIOWS Htaccess Editor bietet in unterstützten Apache-Umgebungen eine verwaltete Oberfläche für die aktive .htaccess. Vor dem Speichern wird automatisch eine Sicherung erstellt. Damit kann die eng gefasste Zugriffssperre nachvollziehbar ergänzt und bei Bedarf zurückgesetzt werden.
Prüfen Sie vor der Änderung, ob die angezeigte Datei im Geltungsbereich der aktiven wp-config.phpliegt. Nach dem Speichern sollten der direkte HTTP-Aufruf blockiert und reguläre WordPress-Funktionen unverändert erreichbar sein. Ein separater Serverzugang bleibt erforderlich, falls ein Fehler das Backend sperrt.
Das Modul ersetzt weder Dateiberechtigungen noch Secret-Management und kann keine Nginx- oder Hosterregel ändern. Öffentlich abgelegte Sicherungen müssen weiterhin entfernt, offengelegte Zugangsdaten ersetzt werden.
Passende AIOWS-Artikel
- Verzeichnisauflistung in WordPress per .htaccess abschalten
- XML-RPC in WordPress mit .htaccess blockieren
- WordPress-Sicherheitsheader mit .htaccess einrichten
Fazit
Sperren Sie den exakten Dateinamen für HTTP-Anfragen, halten Sie die lokalen Dateirechte knapp und entfernen Sie Sicherungskopien aus dem Webroot. Wenn Geheimnisse bereits offengelegt waren, müssen sie unabhängig von der neuen Apache-Regel ersetzt werden.
