Zabezpieczenie wp-config.php w WordPress

Plik wp-config.php w katalogu głównym każdej instalacji WordPress zawiera dane dostępowe do bazy danych (host, nazwa, użytkownik, hasło), tajne klucze bezpieczeństwa i salty oraz kluczowe stałe konfiguracyjne. Jeśli plik ten trafi w niepowołane ręce, praktycznie cała witryna jest skompromitowana. Jest to zatem najważniejszy pojedynczy plik, który należy zabezpieczyć. Ten poradnik pokazuje cztery środki utwardzające: wygenerować świeże klucze bezpieczeństwa, ustawić restrykcyjne uprawnienia plików, zablokować bezpośredni dostęp HTTP do pliku i dodać ochronne stałe takie jak DISALLOW_FILE_EDIT. Opcjonalnie plik można przenieść o poziom powyżej webroota. Wszystkie kroki można wykonać w około 20 minut przez SFTP/SSH oraz konfigurację .htaccess lub nginx.

Krok 1: Odnowienie kluczy bezpieczeństwa i saltów

WordPress używa ośmiu tajnych ciągów znaków (AUTH_KEY, SECURE_AUTH_KEY, LOGGED_IN_KEY, NONCE_KEY i czterech odpowiadających im wartości _SALT), aby szyfrować ciasteczka logowania i nonce'y. Jeśli te wartości były kiedykolwiek publiczne (np. w kopii zapasowej dostępnej w sieci) lub nigdy ich nie zmieniano, powinieneś je odnowić. WordPress udostępnia do tego oficjalny generator:

# Fetch current random values:
https://api.wordpress.org/secret-key/1.1/salt/

W wp-config.php zastąp istniejący blok świeżo wygenerowanymi wartościami:

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' );

Po zapisaniu wszyscy zalogowani użytkownicy zostaną wylogowani – jest to zamierzone i skuteczny sposób na unieważnienie skradzionych sesji.

Krok 2: Ustawienie uprawnień plików

wp-config.php powinien być czytelny dla serwera WWW, ale niedostępny dla innych użytkowników. Zalecane jest 600 (tylko właściciel może czytać/zapisywać) lub 640, jeśli grupa serwera WWW potrzebuje dostępu do odczytu:

# Only owner reads and writes
chmod 600 wp-config.php

# Alternatively, if the web server group must read
chmod 640 wp-config.php

Nigdy nie ustawiaj 777 ani 666 – wtedy każdy użytkownik w systemie może odczytać plik i wydobyć dane dostępowe do bazy danych.

Krok 3: Zablokowanie bezpośredniego dostępu HTTP

Zwykle wp-config.php jest wykonywany jako PHP i nie zwraca żadnego wyniku. Jeśli jednak przetwarzanie PHP zawiedzie (błędna konfiguracja, przenosiny serwera), treść w postaci zwykłego tekstu mogłaby zostać wyświetlona. Zablokuj bezpośredni dostęp dodatkowo na poziomie serwera WWW.

Apache (.htaccess)

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

nginx

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

Krok 4: Dodanie stałych utwardzających

W wp-config.php nad wierszem /* That's all, stop editing! */ dodaj następujące stałe:

// Disable the file editor in the admin area (prevents editing
// theme and plugin code via wp-admin)
define( 'DISALLOW_FILE_EDIT', true );

// Optional: completely prevent installing/updating plugins and
// themes via the dashboard (strictest variant)
// define( 'DISALLOW_FILE_MODS', true );

// Disable debug output in production
define( 'WP_DEBUG', false );
define( 'WP_DEBUG_DISPLAY', false );

// Enforce encrypted connections in the admin area only
define( 'FORCE_SSL_ADMIN', true );

// Limit automatic core updates to security releases
define( 'WP_AUTO_UPDATE_CORE', 'minor' );

DISALLOW_FILE_EDIT jest szczególnie ważny: bez tej stałej atakujący, który przejmie konto administratora, może wykonać dowolny kod PHP bezpośrednio przez Wygląd » Edytor motywu.

Opcjonalnie: Przeniesienie wp-config.php poza webroot

WordPress szuka wp-config.php także o jeden poziom katalogu powyżej webroota. Jeśli Twój WordPress znajduje się w /var/www/html/, możesz przenieść plik do /var/www/wp-config.php. Znajdzie się wtedy poza obszarem osiągalnym przez HTTP.

Uwaga: Działa to niezawodnie tylko w klasycznych instalacjach jednowitrynowych z własnym webrootem. Na hostingu współdzielonym, gdzie wiele witryn dzieli ten sam poziom nadrzędny, przeniesienie może powodować konflikty. W razie wątpliwości skonsultuj się z hostingiem.

Jak sprawdzić, czy zabezpieczenie działa?

1. Otwórz https://twoja-domena.pl/wp-config.php w przeglądarce. Oczekiwane: pusta strona (wykonanie PHP) lub 403 Forbidden (dostęp zablokowany) – nigdy czytelny kod źródłowy PHP.
2. Przez terminal:

   curl -s -o /dev/null -w "%{http_code}\n" https://your-domain.com/wp-config.php
   # Expected: 403 (with an active block) or 200 with an empty body

3. Sprawdzenie uprawnień:

   ls -l wp-config.php
   # Expected: -rw------- (600) or -rw-r----- (640)

4. W panelu administracyjnym sprawdź, że w Wygląd i Wtyczki nie pojawia się już edytor (efekt DISALLOW_FILE_EDIT).

Częste błędy

• Zbyt restrykcyjne uprawnienia: U niektórych hostingów PHP nie działa jako właściciel pliku. Wtedy 600 może powodować błąd 500 – w takim przypadku użyj 640 lub 644.
• Klucze wymienione bez kopii zapasowej: Wykonaj kopię pliku przed zmianami. Literówka w stałych wyłącza witrynę.
• DISALLOW_FILE_MODS zbyt wcześnie: Ta stała blokuje także zwykłe aktualizacje wtyczek/motywów przez panel. Ustaw ją tylko wtedy, gdy aktualizacje przebiegają wyłącznie przez deployment/WP-CLI.
• Plik przeniesiony, ale zła ścieżka: Przy przenoszeniu poza webroot nie twórz własnego loadera require, który ujawnia bezwzględną ścieżkę serwera.

Często zadawane pytania (FAQ)

Jakie uprawnienie powinien mieć wp-config.php?

Zalecane jest 600 (tylko właściciel może czytać i zapisywać). Jeśli na Twoim hostingu PHP nie działa jako właściciel pliku, lecz przez grupę, użyj 640. Nigdy nie ustawiaj 777 ani 666, bo wtedy każdy użytkownik na serwerze może odczytać dane dostępowe do bazy danych.

Co się stanie, gdy zmienię klucze bezpieczeństwa w wp-config.php?

Wszyscy zalogowani użytkownicy zostaną wylogowani i muszą zalogować się ponownie. Jest to zamierzone i skuteczny sposób na unieważnienie skradzionych ciasteczek sesji. Zawartość strony pozostaje bez zmian. Wygeneruj świeże wartości za pomocą oficjalnego generatora tajnych kluczy WordPress.

Do czego służy stała DISALLOW_FILE_EDIT?

DISALLOW_FILE_EDIT wyłącza edytor motywów i wtyczek w panelu administracyjnym WordPress. Bez tej stałej atakujący, który przejmie konto administratora, może wykonać dowolny kod PHP bezpośrednio przez Wygląd » Edytor motywu. Stała jest więc jednym z najważniejszych środków utwardzających.

Czy powinienem przenieść wp-config.php poza webroot?

WordPress szuka wp-config.php także o jeden poziom katalogu powyżej webroota. W klasycznych instalacjach jednowitrynowych z własnym webrootem przeniesienie zwiększa bezpieczeństwo. Na hostingu współdzielonym, gdzie wiele witryn dzieli ten sam poziom nadrzędny, może to powodować konflikty – w razie wątpliwości skonsultuj się z hostingiem.

Jak InspectWP pomaga przy wp-config.php?

Podczas crawla InspectWP sprawdza między innymi, czy wrażliwe pliki takie jak wp-config.php lub kopia wp-config.php.bak są publicznie dostępne, czy panel administracyjny jest wymuszany przez HTTPS oraz czy wyniki debugowania wyciekają na zewnątrz. Odpowiednie znaleziska są oznaczane w raporcie jako ryzyko bezpieczeństwa.