WordPress jest najpopularniejszym systemem CMS na świecie, a co za tym idzie - najczęściej atakowanym. W tym poradniku przedstawiam sprawdzone metody zabezpieczenia strony WordPress.

Dlaczego WordPress jest atakowany?

  • Popularność - ponad 40% stron w internecie używa WordPress
  • Nieaktualizowane instalacje - główna przyczyna włamań
  • Pirackie wtyczki i motywy - często zawierają malware
  • Słabe hasła - łatwe do złamania metodą brute force

Podstawowe zabezpieczenia

1. Zawsze aktualizuj WordPress

To najważniejsza zasada. Aktualizuj:

  • Rdzeń WordPress
  • Wszystkie wtyczki
  • Motyw (theme)

Większość ataków wykorzystuje znane luki w starszych wersjach.

2. Unikaj pirackich wtyczek i motywów

“Darmowe” wersje płatnych produktów często zawierają:

  • Backdoory
  • Kod spamiący
  • Przekierowania na obce strony

Korzystaj tylko z oficjalnych źródeł.

3. Usuń nieużywane wtyczki i motywy

Każda wtyczka to potencjalna luka. Jeśli czegoś nie używasz - usuń to (nie tylko dezaktywuj).

4. Ukryj numer wersji WordPressa

Dodaj do functions.php:

remove_action('wp_head', 'wp_generator');

Zaawansowane zabezpieczenia

5. Nagłówki bezpieczeństwa

Dodaj do .htaccess:

# X-XSS-Protection
Header set X-XSS-Protection "1; mode=block"

# X-Frame-Options (ochrona przed clickjacking)
Header always set X-Frame-Options "SAMEORIGIN"

# X-Content-Type-Options
Header set X-Content-Type-Options "nosniff"

6. Ogranicz dostęp do wp-admin

Możesz ograniczyć dostęp do panelu tylko dla wybranych IP. Dodaj do .htaccess w folderze wp-admin:

order deny,allow
deny from all
allow from TWOJE.IP.ADRES

7. Włącz SSL (HTTPS)

Darmowe certyfikaty SSL są dostępne przez Let’s Encrypt. HTTPS chroni dane przesyłane między przeglądarką a serwerem.

8. Zmień prefix tabel w bazie danych

Domyślny prefix wp_ ułatwia ataki SQL injection. Przy nowej instalacji użyj niestandardowego prefixu.

9. Wyłącz wbudowany edytor plików

Panel WordPressa pozwala edytować pliki motywu i wtyczek prosto z przeglądarki (Wygląd → Edytor). Dla atakującego, który przejmie konto administratora, to gotowe narzędzie do wstrzyknięcia backdoora — bez dotykania FTP. Wyłącz je, dodając do wp-config.php:

define('DISALLOW_FILE_EDIT', true);

Kopie zapasowe: trzymaj je poza serwerem, nie na nim

Kopia zapasowa ma sens tylko wtedy, gdy przetrwa to, przed czym ma chronić. Jeśli backup leży na tym samym serwerze co strona, to przy włamaniu, awarii dysku albo zaszyfrowaniu konta przez ransomware tracisz jednym ruchem i stronę, i jej kopię. To bardzo częsty błąd: archiwa .zip zalegające w wp-content albo katalogu domowym hostingu dają złudne poczucie bezpieczeństwa, a okazują się bezwartościowe dokładnie w chwili, gdy są potrzebne.

Zasada jest prosta: kopia musi fizycznie opuścić serwer. Zewnętrzna lokalizacja — Google Drive, Amazon S3, Backblaze, prywatny serwer plików — sprawia, że kompromitacja hostingu nie dotyka kopii. To samo dotyczy automatycznych backupów hostingu: są pomocne, ale jeśli trzyma je ten sam dostawca na tej samej infrastrukturze, traktuj je jako wygodę, a nie jedyną linię obrony.

Dlaczego wtyczki do backupów częściej szkodzą, niż pomagają

Wtyczki w stylu UpdraftPlus czy Duplicator wyglądają na najprostsze rozwiązanie, ale na produkcyjnej stronie potrafią narobić więcej problemów, niż rozwiązać:

  • Domyślnie zapisują kopie tam, gdzie nie powinny — w wp-content, czyli na tym samym serwerze, a często w katalogu dostępnym publicznie. Archiwum z całą bazą danych pod zgadywalnym adresem to gotowy wyciek.
  • Robią backup z wnętrza zainfekowanego środowiska. Jeśli strona ma już backdoora, wtyczka spokojnie spakuje go do kopii — przywracasz „czysty” backup, a wraca razem z nim.
  • Padają na większych stronach. Generowanie archiwum w PHP rozbija się o limity pamięci i czasu wykonania. Efekt to ucięte, niekompletne kopie, które wyglądają na poprawne, dopóki nie spróbujesz ich przywrócić.
  • To kolejna wtyczka, czyli kolejna powierzchnia ataku. Narzędzie z dostępem do całej bazy i wszystkich plików samo bywa celem — jak pokazał atak na łańcuch dostaw wtyczek, paradoksalnie obniżając bezpieczeństwo, które miało podnieść.

Jeśli mimo wszystko musisz użyć wtyczki, wymuś na niej wysyłanie kopii do zewnętrznej chmury i nigdy nie zostawiaj ich na serwerze. Pewniejsze są jednak kopie robione poziom niżej: zrzut bazy przez mysqldump i archiwum plików z poziomu serwera (cron), wypychane od razu poza hosting. Różne metody tworzenia kopii rozpisałem w osobnym poradniku o kopiach zapasowych WordPressa.

Trzymaj całą stronę w repozytorium Git

Najskuteczniejsze zabezpieczenie, o którym przy WordPressie prawie nikt nie myśli, to wersjonowanie całej witryny w Git. Rdzeń, motyw, wtyczki i pliki konfiguracyjne trafiają do repozytorium (np. prywatnego na GitHubie albo GitLabie), a Ty masz w każdej chwili dokładny, znany-jako-czysty stan każdego pliku.

Dwie korzyści są tu bezcenne:

  • Repozytorium to z natury kopia poza serwerem. Zdalny remote na GitHubie żyje niezależnie od hostingu — kompromitacja serwera nie dotyka historii w Git.
  • Po ataku natychmiast widzisz, co się zmieniło. Zamiast ręcznie porównywać setki plików z czystą instalacją WordPressa, wpisujesz git status i git diff — i w sekundę masz listę każdego doklejonego, zmienionego i podrzuconego pliku.

To właśnie ten drugi punkt zamienia wielodniowe sprzątanie w precyzyjną operację. Przy ataku w rodzaju japońskiego spamu SEO — gdzie napastnik dokleja kod do wp-config.php i .htaccess, podrzuca backdoora udającego plik systemowy i podmienia sitemapę — git diff świeci na czerwono dokładnie te pliki. wp-config.php, który spuchł z 3 do 9 KB, czy nagle pojawiający się wp-comments-posts.php nie mają jak się ukryć: nie ma ich w historii repozytorium, więc rzucają się w oczy od razu. Przywrócenie czystej wersji to wtedy git checkout, a nie godziny zgadywania.

Dwie rzeczy, o których trzeba pamiętać:

  • Git wersjonuje kod, nie dane. Baza danych i katalog wp-content/uploads (wgrane zdjęcia, pliki) zmieniają się przy normalnym używaniu strony i nie należą do repozytorium — dla nich nadal potrzebujesz kopii bazy i plików (patrz wyżej). Git i backup nie wykluczają się, tylko uzupełniają.
  • Sekrety trzymaj poza repozytorium. Dane dostępowe z wp-config.php wynieś do zmiennych środowiskowych albo dodaj plik do .gitignore, żeby hasła i klucze nie trafiły do historii.

W tym podejściu WordPress przestaje być nietykalną czarną skrzynką na serwerze, a staje się kodem, który masz pod kontrolą — z pełną historią zmian i możliwością cofnięcia każdej z nich.

Jak rozpoznać włamanie?

Objawy zainfekowanej strony:

  • Przekierowania na obce strony
  • Fałszywe pliki jQuery w nagłówku
  • Funkcje eval() w kodzie
  • Zakodowany kod PHP (base64)
  • Podejrzane pliki w katalogach
  • Nowi nieznani administratorzy

Co zrobić po włamaniu?

  1. Przywróć z kopii zapasowej (jeśli masz pewną kopię)
  2. Zablokuj dostęp przez .htaccess podczas naprawy
  3. Zaktualizuj wszystko do najnowszych wersji
  4. Zmień wszystkie hasła (WordPress, FTP, baza danych)
  5. Przeskanuj pliki w poszukiwaniu malware — jeśli trzymasz stronę w Git, git diff od razu pokaże każdy doklejony i podmieniony plik
  6. Zgłoś do Google jeśli strona została oznaczona jako niebezpieczna

Jeśli nie czujesz się na siłach, by samodzielnie usunąć infekcję i przywrócić stronę do działania, zajmuję się tym zawodowo — sprawdź ofertę naprawy zainfekowanego WordPressa.

Podsumowanie

Bezpieczeństwo WordPress to proces ciągły. Regularne aktualizacje, kopie zapasowe trzymane poza serwerem, wersjonowanie strony w Git i podstawowe zabezpieczenia znacząco zmniejszają ryzyko włamania — a gdy już do niego dojdzie, skracają naprawę z dni do godzin. Pamiętaj: prewencja jest tańsza niż naprawa.

Po pełną, oficjalną listę technik hartowania sięgnij do dokumentacji Hardening WordPress.