Hardening wp-config.php

Plik wp-config.php to serce konfiguracji WordPress - zawiera dane dostępowe do bazy danych, klucze szyfrujące sesje użytkowników oraz zaawansowane ustawienia bezpieczeństwa. To najważniejszy plik do zabezpieczenia po instalacji WordPress.

Odpowiednie skonfigurowanie wp-config.php chroni przed:

Przejęciem sesji - słabe security keys umożliwiają podszywanie się pod użytkowników
Edycją plików przez atakujących - włączony edytor w panelu to prosta droga do backdoora
Wyciekiem informacji - włączony debug na produkcji ujawnia strukturę serwera
Atakami man-in-the-middle - brak wymuszenia SSL dla wp-admin

📊 Poziom trudności

Średnio-zaawansowany ⭐⭐

⏱️ Czas wdrożenia: 15-30 minut (opcje 1-5), +15 minut (opcja 6 zaawansowana) 🛠️ Wymagane umiejętności: Podstawowa edycja plików tekstowych, dostęp FTP/Manager plików 💻 Narzędzia: Panel Joton + edytor tekstu (Notepad++, VS Code lub wbudowany w Manager plików)

⚠️ Przed rozpoczęciem - BACKUP!

Błąd składni w wp-config.php może spowodować białą stronę (WSOD - White Screen of Death). Zawsze wykonaj kopię zapasową przed edycją.

Backup przez panel Joton:

Panel Joton → Witryny → Twoja domena → Kopie zapasowe
Kliknij Utwórz kopię zapasową
Poczekaj 2-5 minut → gotowe

Jeśli coś pójdzie nie tak, przywrócisz backup w 1 kliknięcie.

Szczegóły: Kopie zapasowe

Jak edytować wp-config.php

Plik wp-config.php znajduje się w głównym katalogu WordPress (zazwyczaj public_html). Masz 3 metody dostępu:

Metoda 1: Manager plików w panelu Joton (zalecane dla początkujących)

Zalety: Nie wymaga dodatkowego oprogramowania, edytor z podświetlaniem składni

Zaloguj się do panelu Joton: https://login.joton.io/
Witryny → wybierz swoją domenę
Kliknij Pliki w górnym menu
Przejdź do katalogu public_html (lub głównego katalogu WordPress)
Znajdź plik wp-config.php
Kliknij prawym przyciskiem → Edytuj
Wprowadź zmiany (opisane poniżej)
Kliknij Zapisz (prawy górny róg)

Metoda 2: FTP/SFTP

Zalety: Możesz edytować offline w swoim ulubionym edytorze

Połącz się przez FileZilla, Cyberduck lub innego klienta FTP
- Host: twojadomena.pl (lub adres FTP z panelu Joton)
- Użytkownik/Hasło: Panel Joton → FTP
Przejdź do public_html
Pobierz wp-config.php na komputer (prawy klik → Download)
Otwórz w edytorze tekstu (Notepad++, Sublime Text, VS Code)
Wprowadź zmiany
Zapisz plik
Prześlij z powrotem na serwer (nadpisz stary plik)

💡 Zalecane edytory tekstu

Windows: Notepad++ (darmowy) macOS: TextMate, BBEdit Linux: gedit, kate Uniwersalny: Visual Studio Code (darmowy, Windows/macOS/Linux)

NIE używaj: Notatnik Windows (Notepad) - może zepsuć kodowanie UTF-8

Metoda 3: SSH (dla zaawansowanych)

Zalety: Najszybsza metoda, możliwość użycia nano lub vim

Połącz się przez SSH:
bash
```
ssh [email protected]
```
Przejdź do katalogu WordPress:
bash
```
cd ~/public_html
```
Edytuj plik:
bash
```
nano wp-config.php
```
Wprowadź zmiany
Zapisz: Ctrl+O → Enter → Wyjdź: Ctrl+X

Szczegóły SSH: Generowanie kluczy SSH

Opcja 1: Wymiana Security Keys i Salts

Poziom: ⭐ Początkujący | Czas: 3 minuty | Priorytet: 🔴 Wysoki

Czym są security keys?

Security keys to 8 losowych ciągów znaków używanych przez WordPress do szyfrowania haseł w ciasteczkach (cookies). Gdy użytkownik się loguje, WordPress zapisuje zaszyfrowaną sesję w przeglądarce. Jeśli atakujący zna klucze szyfrujące, może:

Podszywać się pod użytkowników bez znajomości haseł
Przejąć sesje administratorów (Session Hijacking)
Ominąć 2FA (jeśli sesja jest już uwierzytelniona)

Kiedy wymienić klucze?

Sytuacja	Kiedy	Priorytet
Po instalacji WordPress	Jeśli instalator użył domyślnych/słabych kluczy	Wysoki
Po podejrzeniu włamania	Natychmiast (wymusza wylogowanie wszystkich)	Krytyczny
Proaktywna rotacja	Co 6-12 miesięcy	Średni
Po zmianie hosta	Przy migracji na nowy serwer	Średni

Jak wymienić security keys

Krok 1: Wygeneruj nowe klucze

Otwórz w przeglądarce: https://api.wordpress.org/secret-key/1.1/salt/
Zobaczysz 8 linii kodu PHP, każda zaczyna się od define(
Skopiuj cały kod (Ctrl+A → Ctrl+C)

Przykład wygenerowanego kodu:

php

define('AUTH_KEY',         'p6^n-v|K9/gJZ3<Wq1r7NmY[L5hD...');
define('SECURE_AUTH_KEY',  'u8*F}sT2bX!cR4eP@jM6vK#...');
define('LOGGED_IN_KEY',    'aB3$xC9%yD7&zE1^fG5*hH2...');
define('NONCE_KEY',        'iJ4(kL8)mN6#oP0!qR2@sT5...');
define('AUTH_SALT',        'uV3$wX7%yZ1&aB5*cD9^eF2...');
define('SECURE_AUTH_SALT', 'gH6(iJ0)kL4#mN8!oP2@qR6...');
define('LOGGED_IN_SALT',   'sT1$uV5%wX9&yZ3*aB7^cD1...');
define('NONCE_SALT',       'eF5(gH9)iJ3#kL7!mN1@oP5...');

Krok 2: Otwórz wp-config.php

(użyj jednej z metod opisanych wyżej)

Krok 3: Znajdź sekcję security keys

Szukaj komentarza:

php

/**#@+
 * Authentication unique keys and salts.
 */

Poniżej zobaczysz 8 linii zaczynających się od define('AUTH_KEY'...

Krok 4: Zamień starą sekcję na nową

Zaznacz wszystkie 8 linii define (od AUTH_KEY do NONCE_SALT)
Usuń (Delete)
Wklej nowo wygenerowany kod (Ctrl+V)
Zapisz plik

Przed:

php

/**#@+
 * Authentication unique keys and salts.
 */
define('AUTH_KEY',         'put your unique phrase here');
define('SECURE_AUTH_KEY',  'put your unique phrase here');
// ... (stare, słabe klucze)

Po:

php

/**#@+
 * Authentication unique keys and salts.
 */
define('AUTH_KEY',         'p6^n-v|K9/gJZ3<Wq1r7NmY[L5hD...');
define('SECURE_AUTH_KEY',  'u8*F}sT2bX!cR4eP@jM6vK#...');
// ... (nowe, losowe klucze z generatora)

Weryfikacja i efekt uboczny

⚠️ Wszyscy użytkownicy zostaną wylogowani

Po zmianie security keys każdy zalogowany użytkownik (włącznie z Tobą) zostanie automatycznie wylogowany. To normalne i oczekiwane zachowanie.

Co zrobić po zmianie:

Zaloguj się ponownie do wp-admin ze swoim hasłem
Lub użyj SSO z panelu Joton: Witryny → WordPress → Zaloguj się

Zobacz: Reset hasła WordPress - SSO

Sprawdź czy działa:

Otwórz stronę w przeglądarce (tryb incognito)
Spróbuj zalogować się do wp-admin
Jeśli logowanie działa = klucze wymienione poprawnie

Opcja 2: Wyłączenie edytora plików w panelu WordPress

Poziom: ⭐ Początkujący | Czas: 1 minuta | Priorytet: 🔴 Wysoki

Czym jest edytor plików?

WordPress domyślnie pozwala administratorom edytować kod PHP wtyczek i motywów bezpośrednio z panelu wp-admin:

Wygląd → Edytor motywu
Wtyczki → Edytor plików

Dlaczego to zagrożenie?

Jeśli atakujący zdobędzie dostęp do konta administratora (np. przez słabe hasło, phishing, exploit wtyczki), może:

Wejść do Wygląd → Edytor motywu
Otworzyć plik functions.php
Wstrzyknąć backdoor (złośliwy kod PHP)
Zapisać
Backdoor działa - atakujący ma trwały dostęp nawet po zmianie hasła

Przykład backdoora (NIE KOPIUJ!):

php

<?php
// Atakujący może wykonać dowolny kod przez URL
if (isset($_GET['cmd'])) {
    eval(base64_decode($_GET['cmd']));
}
?>

Jak wyłączyć edytor

Dodaj jedną linię do wp-config.php:

Otwórz wp-config.php
Znajdź komentarz /* That's all, stop editing! Happy publishing. */
PRZED tym komentarzem dodaj:

php

// Wyłączenie edytora plików w panelu WordPress
define('DISALLOW_FILE_EDIT', true);

Pełny przykład (fragment wp-config.php):

php

// ... inne ustawienia WordPress ...

// Wyłączenie edytora plików w panelu WordPress
define('DISALLOW_FILE_EDIT', true);

/* That's all, stop editing! Happy publishing. */

if ( ! defined( 'ABSPATH' ) ) {
    define( 'ABSPATH', __DIR__ . '/' );
}

require_once ABSPATH . 'wp-settings.php';

Zapisz plik

Weryfikacja

Zaloguj się do WordPress (wp-admin)
Przejdź do Wygląd - opcja "Edytor motywu" powinna zniknąć
Przejdź do Wtyczki - opcja "Edytor plików" powinna zniknąć

💡 Jak edytować pliki po wyłączeniu edytora?

Ty (jako właściciel hostingu) nadal możesz edytować pliki przez:

FTP/SFTP (FileZilla, Cyberduck)
Manager plików Joton (Panel → Pliki)
SSH (nano, vim)

Wyłączenie edytora dotyczy tylko panelu WordPress, nie Twoich uprawnień na serwerze.

Opcja 3: Wyłączenie debugowania na produkcji

Poziom: ⭐ Początkujący | Czas: 1 minuta | Priorytet: 🟡 Średni

Czym jest WP_DEBUG?

WP_DEBUG to tryb deweloperski WordPress, który wyświetla szczegółowe komunikaty błędów:

Ścieżki do plików na serwerze (/home/user/public_html/wp-content/plugins/...)
Zapytania SQL i błędy bazy danych
Stack traces (lista wywołanych funkcji PHP)
Deprecated functions (przestarzałe funkcje)

Dlaczego to zagrożenie na produkcji?

Komunikaty błędów ujawniają atakującemu:

Strukturę katalogów - gdzie znajdują się wrażliwe pliki
Wersje wtyczek - może wyszukać exploity dla konkretnej wersji
Zapytania SQL - pomoc w konstruowaniu ataków SQL injection
Nazwy użytkowników - z błędów MySQL (SELECT * FROM wp_users WHERE user_login = 'admin')

Przykład błędu debug (NIE chcesz tego na produkcji):

Warning: include(/home/joton123/public_html/wp-content/plugins/old-plugin/functions.php):
failed to open stream in /home/joton123/public_html/wp-includes/plugin.php on line 423

Stack trace:
#0 /home/joton123/public_html/wp-settings.php(275): require()
#1 /home/joton123/public_html/wp-config.php(95): require_once()

Atakujący widzi: ścieżkę, nazwy wtyczek, wersję PHP, strukturę wywołań.

Konfiguracja dla strony produkcyjnej

W wp-config.php znajdź:

php

define('WP_DEBUG', false);

Upewnij się że wartość to false:

define('WP_DEBUG', false); - POPRAWNE (debug wyłączony)
❌ define('WP_DEBUG', true); - NIEBEZPIECZNE (debug włączony)

Jeśli linii nie ma, dodaj przed /* That's all... */:

php

// Wyłączenie debugowania na produkcji
define('WP_DEBUG', false);

Konfiguracja dla środowiska staging/dev

Jeśli testujesz zmiany na środowisku staging (zobacz: Przewodnik po staging), możesz włączyć debug z logowaniem do pliku (nie wyświetlając na stronie):

php

// Debug na staging - logi do pliku, NIE wyświetlaj na stronie
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);        // Zapisuj błędy do wp-content/debug.log
define('WP_DEBUG_DISPLAY', false);   // NIE wyświetlaj błędów na stronie
@ini_set('display_errors', 0);       // Wymuś ukrycie błędów PHP

Jak czytać logi:

FTP → wp-content/debug.log
Lub Manager plików Joton → public_html/wp-content/debug.log

💡 Staging w panelu Joton

Panel Joton pozwala tworzyć oddzielne środowiska staging z domeną *.joton.dev. Możesz tam bezpiecznie włączyć debug, testować aktualizacje, a potem opublikować na produkcję.

Szczegóły: Przewodnik po staging

Opcja 4: Wymuszenie SSL dla panelu administracyjnego

Poziom: ⭐ Początkujący | Czas: 1 minuta | Priorytet: 🟡 Średni

Dlaczego wymuszać SSL dla wp-admin?

Nawet jeśli Twoja strona ma certyfikat SSL (zobacz: SSL oraz Let's Encrypt), WordPress nie wymusza automatycznie HTTPS dla panelu wp-admin.

Bez FORCE_SSL_ADMIN:

Użytkownik może przypadkowo wejść na http://domena.pl/wp-admin/ (HTTP)
Hasło przesyłane niezaszyfrowane (plain text przez sieć)
Atakujący w tej samej sieci WiFi (kawiarnia, lotnisko) może przechwycić hasło (Man-in-the-Middle)

Z FORCE_SSL_ADMIN:

WordPress automatycznie przekierowuje http:// → https:// dla wp-admin
Hasło zawsze szyfrowane (SSL/TLS)
Sesja administratora chroniona przed MITM

Jak włączyć wymuszenie SSL

Dodaj w wp-config.php przed /* That's all... */:

php

// Wymuszenie HTTPS dla panelu wp-admin
define('FORCE_SSL_ADMIN', true);

Weryfikacja

Otwórz przeglądarkę (tryb incognito)
Spróbuj wejść na: http://twojadomena.pl/wp-admin/ (HTTP, bez "s")
WordPress powinien automatycznie przekierować na https://twojadomena.pl/wp-admin/ (HTTPS)
Sprawdź pasek adresu - powinna być kłódka 🔒

💡 Wymuszenie HTTPS dla całej strony

FORCE_SSL_ADMIN chroni tylko panel wp-admin. Aby wymusić HTTPS dla całej strony (włącznie z frontendem), użyj funkcji w panelu Joton:

Panel Joton → Witryny → Zaawansowane → Bezpieczeństwo → SSL/TLS → Wymuszanie protokołu HTTPS

Szczegóły: SSL oraz Let's Encrypt

Opcja 5: Kontrola automatycznych aktualizacji

Poziom: ⭐⭐ Średnio-zaawansowany | Czas: 2 minuty | Priorytet: 🟡 Średni

Czym są automatyczne aktualizacje WordPress?

WordPress domyślnie automatycznie aktualizuje:

Minor releases (np. 6.4.1 → 6.4.2) - poprawki bezpieczeństwa
Tłumaczenia (polskie tłumaczenia WordPress)
Opcjonalnie: Major releases (np. 6.4 → 6.5), wtyczki, motywy

Problem z automatycznymi aktualizacjami

Plusy:

Zawsze najnowsze poprawki bezpieczeństwa (CVE załatane automatycznie)
Nie musisz pamiętać o aktualizacjach

Minusy:

❌ Aktualizacja może popsuć stronę jeśli wtyczka/motyw nie jest kompatybilny
❌ Brak kontroli - aktualizacja może nastąpić w szczycie ruchu
❌ Nie testujesz najpierw na staging

Zalecana konfiguracja dla produkcji

Strategia: Automatyczne minor (security patches), ręczne major (testowanie na staging)

Dodaj w wp-config.php:

php

// Automatyczne aktualizacje tylko dla minor releases (poprawki bezpieczeństwa)
define('WP_AUTO_UPDATE_CORE', 'minor');

// Wyłączenie auto-update dla wtyczek i motywów
add_filter('auto_update_plugin', '__return_false');
add_filter('auto_update_theme', '__return_false');

Opcje WP_AUTO_UPDATE_CORE

Wartość	Co aktualizuje	Zalecane dla
`true`	Wszystkie (major + minor)	NIE - ryzykowne dla produkcji
`false`	Żadnych automatycznych	Tylko jeśli regularnie ręcznie sprawdzasz (co tydzień)
`'minor'`	Tylko minor (security patches)	ZALECANE - balans bezpieczeństwo/stabilność

Workflow z partial auto-update

Minor releases aktualizują się automatycznie (np. 6.4.1 → 6.4.2)
- To poprawki bezpieczeństwa (CVE)
- Rzadko psują kompatybilność
Major releases testujesz ręcznie:
- Utwórz staging (Panel Joton → Strona testowa)
- Zaktualizuj WordPress na staging (np. 6.4 → 6.5)
- Przetestuj stronę (formularz kontaktowy, sklep, płatności)
- Jeśli OK → zaktualizuj produkcję
Wtyczki i motywy aktualizujesz ręcznie:
- Co tydzień: Panel → Aktualizacje - sprawdź dostępne
- Czytaj changelog - co się zmieniło
- Testuj na staging jeśli duża aktualizacja (np. WooCommerce 8.x → 9.x)

⚠️ Kompromis: bezpieczeństwo vs stabilność

Wyłączenie automatycznych aktualizacji zwiększa ryzyko exploitów (niezałatane luki). Musisz regularnie sprawdzać dostępne aktualizacje ręcznie.

Zalecamy:

Włącz auto-update dla minor releases (WP_AUTO_UPDATE_CORE = 'minor')
Wyłącz dla major/wtyczek/motywów
Co tydzień sprawdzaj: wp-admin → Panel → Aktualizacje
Testuj major updates na staging przed produkcją

Opcja 6: Zmiana prefiksu tabel bazy danych (zaawansowane)

Poziom: ⭐⭐⭐ Zaawansowany | Czas: 5-20 minut | Priorytet: 🟢 Niski

⚠️ Zaawansowane - dla doświadczonych użytkowników

Zmiana prefiksu wymaga edycji bazy danych i może popsuć stronę jeśli zrobiona niepoprawnie.

NIE zalecamy początkującym - opcje 1-5 dają lepszy stosunek bezpieczeństwo/ryzyko.

Jeśli jesteś początkujący:

Zrób opcje 1-5 (security keys, DISALLOW_FILE_EDIT, debug, SSL, auto-update)
Zainstaluj wtyczkę bezpieczeństwa (Wordfence/iThemes)
Włącz 2FA
⏩ Pomiń zmianę prefiksu tabel (marginalny zysk bezpieczeństwa, wysokie ryzyko pomyłki)

Jeśli masz doświadczenie z phpMyAdmin i backupami:

Możesz spróbować, ale najpierw:
1. Pełny backup (Panel Joton + pobranie lokalnie)
2. Test na środowisku staging
3. Postępuj według instrukcji poniżej

Czym jest prefiks tabel?

WordPress przechowuje dane w bazie MySQL w tabelach:

wp_users - użytkownicy
wp_posts - posty i strony
wp_options - ustawienia
wp_postmeta - metadane postów
... (łącznie ~12 tabel)

Prefiks wp_ jest domyślny dla wszystkich instalacji WordPress.

Dlaczego to (słabe) zagrożenie?

Atakujący znają nazwy tabel WordPress. W ataku SQL injection mogą próbować:

sql

-- Exploit SQL injection - próba odczytania użytkowników
SELECT * FROM wp_users WHERE ID=1;

Jeśli Twój prefiks to wp_, zapytanie zadziała. Jeśli jt2024_, zapytanie zwróci błąd (tabela wp_users nie istnieje).

ALE: To security through obscurity (bezpieczeństwo przez ukrywanie), nie prawdziwa ochrona. Lepsze zabezpieczenia:

Aktualizacje WordPress/wtyczek (załatane luki SQL injection)
Wtyczka WAF (Wordfence) - blokuje złośliwe zapytania SQL
Redis cache - zmniejsza obciążenie MySQL

Zmiana prefiksu przy NOWEJ instalacji (bezpieczne)

Jeśli dopiero instalujesz WordPress:

Przed uruchomieniem instalatora edytuj wp-config.php
Znajdź:
php
```
$table_prefix = 'wp_';
```

Zmień na unikalny prefiks (litery, cyfry, podkreślnik):

php

$table_prefix = 'jt2024_';  // Przykład - wymyśl własny

Zapisz plik
Uruchom instalator WordPress (http://twojadomena.pl/wp-admin/install.php)
Tabele zostaną utworzone z nowym prefiksem (jt2024_users, jt2024_posts, ...)

Zmiana prefiksu na ISTNIEJĄCEJ stronie (ryzykowne)

Wymaga 3 kroków:

Zmiana $table_prefix w wp-config.php
Zmiana nazw tabel w bazie danych (przez phpMyAdmin lub wtyczkę)
Aktualizacja wartości w kolumnach wp_options i wp_usermeta

Zalecamy wtyczkę: Change Table Prefix

Instalacja wtyczki:

Wtyczki → Dodaj nową → Wyszukaj: Change Table Prefix
Instaluj → Aktywuj
Settings → Change DB Prefix
Wprowadź nowy prefiks (np. jt2024_)
Kliknij Change DB Prefix
Poczekaj 1-5 minut (zależy od rozmiaru bazy)
Sprawdź czy strona działa

Wtyczka automatycznie:

Zmieni nazwy wszystkich tabel (wp_* → jt2024_*)
Zaktualizuje $table_prefix w wp-config.php
Zaktualizuje wartości w wp_options.option_name i wp_usermeta.meta_key

Jeśli wolisz ręcznie (bardzo zaawansowane):

Szczegóły w oficjalnej dokumentacji: WordPress.org - Changing Database Prefix

Przykładowa konfiguracja wp-config.php (kompletna)

Po zastosowaniu wszystkich powyższych opcji (1-5, opcję 6 pominięto), sekcja bezpieczeństwa w wp-config.php powinna wyglądać tak:

php

<?php
/**
 * WordPress configuration file
 *
 * @package WordPress
 */

// === 1. Security Keys (wygenerowane z https://api.wordpress.org/secret-key/1.1/salt/) ===
define('AUTH_KEY',         'skopiuj-klucz-z-generatora-tutaj');
define('SECURE_AUTH_KEY',  'skopiuj-klucz-z-generatora-tutaj');
define('LOGGED_IN_KEY',    'skopiuj-klucz-z-generatora-tutaj');
define('NONCE_KEY',        'skopiuj-klucz-z-generatora-tutaj');
define('AUTH_SALT',        'skopiuj-klucz-z-generatora-tutaj');
define('SECURE_AUTH_SALT', 'skopiuj-klucz-z-generatora-tutaj');
define('LOGGED_IN_SALT',   'skopiuj-klucz-z-generatora-tutaj');
define('NONCE_SALT',       'skopiuj-klucz-z-generatora-tutaj');

// === 2. Wyłączenie edytora plików ===
define('DISALLOW_FILE_EDIT', true);

// === 3. Wyłączenie debugowania na produkcji ===
define('WP_DEBUG', false);

// === 4. Wymuszenie SSL dla wp-admin ===
define('FORCE_SSL_ADMIN', true);

// === 5. Kontrola automatycznych aktualizacji ===
define('WP_AUTO_UPDATE_CORE', 'minor');  // Tylko security patches
add_filter('auto_update_plugin', '__return_false');
add_filter('auto_update_theme', '__return_false');

// === Standardowa konfiguracja WordPress (NIE ZMIENIAJ poniżej) ===
define('DB_NAME', 'twoja_baza_danych');
define('DB_USER', 'twoj_uzytkownik_mysql');
define('DB_PASSWORD', 'twoje_haslo_mysql');
define('DB_HOST', 'localhost');
define('DB_CHARSET', 'utf8mb4');
define('DB_COLLATE', '');

$table_prefix = 'wp_';  // Lub własny prefiks jeśli używasz opcji 6

/* That's all, stop editing! Happy publishing. */

if ( ! defined( 'ABSPATH' ) ) {
    define( 'ABSPATH', __DIR__ . '/' );
}

require_once ABSPATH . 'wp-settings.php';

💡 Skopiuj i dostosuj

Możesz skopiować powyższy przykład, ale pamiętaj:

Wygeneruj własne security keys (nie używaj przykładowych!)
Uzupełnij poprawnie DB_NAME, DB_USER, DB_PASSWORD (z Twojego panelu Joton)
Zapisz backup przed nadpisaniem oryginalnego wp-config.php

Weryfikacja zmian - checklist

Po zastosowaniu wszystkich opcji (1-5), sprawdź:

[ ] Strona działa poprawnie (otwórz w przeglądarce)
[ ] Możesz zalogować się do wp-admin (nowe hasło po zmianie keys)
[ ] Opcja "Edytor motywu" zniknęła z menu Wygląd
[ ] Opcja "Edytor plików" zniknęła z menu Wtyczki
[ ] Brak komunikatów błędów na stronie (debug wyłączony)
[ ] Wejście na http://domena.pl/wp-admin/ przekierowuje na https:// (SSL)
[ ] Minor updates WordPress działają automatycznie (sprawdź za tydzień)

⚠️ Biała strona (WSOD) po zapisaniu wp-config.php?

Jeśli po zapisaniu widzisz białą stronę bez żadnego tekstu, prawdopodobnie błąd składni PHP w wp-config.php.

Natychmiastowe rozwiązanie:

Przywróć backup pliku przez FTP/Manager plików Joton
Sprawdź co poszło nie tak:
- Czy wszystkie apostrofy są zamknięte? ('wartość')
- Czy średniki na końcu linii? (define(...);)
- Czy brak polskich znaków w komentarzach?
- Czy nie skopiowałeś numeru linii z edytora? (123: define(...) zamiast define(...))
Spróbuj ponownie - edytuj ostrożniej
Lub zgłoś się do supportu przez Panel klienta → Support → Nowe zgłoszenie (login.joton.io)

Następne kroki

Po zabezpieczeniu wp-config.php przejdź do:

Ochrona przed brute-force - limit prób logowania, zmiana URL wp-login.php, 2FA
Wtyczki bezpieczeństwa - firewall, skanowanie malware, monitoring (Wordfence/iThemes/Sucuri)
Monitoring i audyt - logi aktywności, wykrywanie zagrożeń, audyty kwartalne

Przydatne linki

WordPress.org - Hardening WordPress - oficjalna dokumentacja bezpieczeństwa
Security Keys Generator - generator kluczy szyfrujących
Reset hasła WordPress - SSO, WordPress Toolkit
Kopie zapasowe - backup przed każdą większą zmianą
Przewodnik po staging - testowanie zmian w bezpiecznym środowisku

Powrót do: Bezpieczeństwo WordPress

Hardening wp-config.php ​

Jak edytować wp-config.php ​

Metoda 1: Manager plików w panelu Joton (zalecane dla początkujących) ​

Metoda 2: FTP/SFTP ​

Metoda 3: SSH (dla zaawansowanych) ​

Opcja 1: Wymiana Security Keys i Salts ​

Czym są security keys? ​

Kiedy wymienić klucze? ​

Jak wymienić security keys ​

Weryfikacja i efekt uboczny ​

Opcja 2: Wyłączenie edytora plików w panelu WordPress ​

Czym jest edytor plików? ​

Dlaczego to zagrożenie? ​

Jak wyłączyć edytor ​

Weryfikacja ​

Opcja 3: Wyłączenie debugowania na produkcji ​

Czym jest WP_DEBUG? ​

Dlaczego to zagrożenie na produkcji? ​

Konfiguracja dla strony produkcyjnej ​

Konfiguracja dla środowiska staging/dev ​

Opcja 4: Wymuszenie SSL dla panelu administracyjnego ​

Dlaczego wymuszać SSL dla wp-admin? ​

Jak włączyć wymuszenie SSL ​

Weryfikacja ​

Opcja 5: Kontrola automatycznych aktualizacji ​

Czym są automatyczne aktualizacje WordPress? ​

Problem z automatycznymi aktualizacjami ​

Zalecana konfiguracja dla produkcji ​

Opcje WP_AUTO_UPDATE_CORE ​

Workflow z partial auto-update ​

Opcja 6: Zmiana prefiksu tabel bazy danych (zaawansowane) ​

Czym jest prefiks tabel? ​

Dlaczego to (słabe) zagrożenie? ​

Zmiana prefiksu przy NOWEJ instalacji (bezpieczne) ​

Zmiana prefiksu na ISTNIEJĄCEJ stronie (ryzykowne) ​

Przykładowa konfiguracja wp-config.php (kompletna) ​

Weryfikacja zmian - checklist ​

Następne kroki ​

Przydatne linki ​

Hardening wp-config.php

Jak edytować wp-config.php

Metoda 1: Manager plików w panelu Joton (zalecane dla początkujących)

Metoda 2: FTP/SFTP

Metoda 3: SSH (dla zaawansowanych)

Opcja 1: Wymiana Security Keys i Salts

Czym są security keys?

Kiedy wymienić klucze?

Jak wymienić security keys

Weryfikacja i efekt uboczny

Opcja 2: Wyłączenie edytora plików w panelu WordPress

Czym jest edytor plików?

Dlaczego to zagrożenie?

Jak wyłączyć edytor

Weryfikacja

Opcja 3: Wyłączenie debugowania na produkcji

Czym jest WP_DEBUG?

Dlaczego to zagrożenie na produkcji?

Konfiguracja dla strony produkcyjnej

Konfiguracja dla środowiska staging/dev

Opcja 4: Wymuszenie SSL dla panelu administracyjnego

Dlaczego wymuszać SSL dla wp-admin?

Jak włączyć wymuszenie SSL

Weryfikacja

Opcja 5: Kontrola automatycznych aktualizacji

Czym są automatyczne aktualizacje WordPress?

Problem z automatycznymi aktualizacjami

Zalecana konfiguracja dla produkcji

Opcje WP_AUTO_UPDATE_CORE

Workflow z partial auto-update

Opcja 6: Zmiana prefiksu tabel bazy danych (zaawansowane)

Czym jest prefiks tabel?

Dlaczego to (słabe) zagrożenie?

Zmiana prefiksu przy NOWEJ instalacji (bezpieczne)

Zmiana prefiksu na ISTNIEJĄCEJ stronie (ryzykowne)

Przykładowa konfiguracja wp-config.php (kompletna)

Weryfikacja zmian - checklist

Następne kroki

Przydatne linki