WordPress to 43% internetu — i cel numer jeden dla botów skanujących luki. Nie dlatego, że WordPress jest niebezpieczny. Dlatego, że większość instalacji jest źle zabezpieczona: domyślny login admin, brak 2FA, nieaktualizowane wtyczki i zero monitoringu. Poniżej opisujemy checklist bezpieczeństwa, który stosujemy na każdym wdrożeniu — bez wtyczek all-in-one typu Wordfence czy Sucuri, które same stają się wektorem ataku (kolejna wtyczka z dostępem do całego systemu).
Aktualizacje — najważniejsza warstwa obrony
80% włamań do WordPressa wykorzystuje znane luki w nieaktualizowanych wtyczkach. Nie zero-day, nie wyrafinowane ataki — po prostu stare wersje wtyczek z opublikowanymi CVE.
Nasza polityka aktualizacji:
- Core WordPress — auto-update minor (5.9.1 → 5.9.2) włączony. Major (5.9 → 6.0) — ręcznie po testach na staging.
- Wtyczki — auto-update dla wtyczek bezpieczeństwa (firewall, 2FA). Pozostałe — ręcznie co tydzień. Przed aktualizacją: backup bazy i plików.
- Motywy — jeśli custom motyw — nie dotyczy. Jeśli gotowy motyw — aktualizacja jak wtyczki.
- PHP — minimum PHP 8.1. Starsze wersje (7.4, 8.0) nie otrzymują już poprawek bezpieczeństwa.
Logowanie — ukrycie i zabezpieczenie wp-login
Domyślny /wp-login.php to zaproszenie dla brute-force botów. Co robimy:
- Zmiana URL logowania — przenosimy /wp-login.php na niestandardowy adres (np. /panel-logowania). Nie przez wtyczkę — przez prostą regułę w .htaccess lub nginx config.
- 2FA (dwuskładnikowe uwierzytelnianie) — obowiązkowe dla każdego konta admina. Używamy WP 2FA lub miniOrange. Google Authenticator, nie SMS (SMS jest podatny na SIM swapping).
- Limit prób logowania — maksimum 5 prób na 15 minut. Po przekroczeniu — blokada IP na 1 godzinę. Konfiguracja w .htaccess lub fail2ban na serwerze.
- Wyłączenie XML-RPC — XML-RPC to stary protokół, który pozwala na zdalne logowanie. Jeśli nie używasz aplikacji mobilnej WordPress — wyłącz:
<Files xmlrpc.php> Deny from all </Files>
Uprawnienia plików i katalogów
Złe uprawnienia plików to otwarte drzwi. Checklist:

