Blog · 6 listopada 2026 · 9 min czytania

WordPress: 10 ustawień bezpieczeństwa na godzinę

Włamania na firmowe strony na WordPressie rzadko są dziełem geniusza. Prawie zawsze to automat, który przeczesuje internet w poszukiwaniu kilku tych samych dziur: nieaktualnej wtyczki, konta „admin” ze słabym hasłem, otwartego logowania bez limitu prób. Poniżej dziesięć ustawień, które te drogi zamykają. Żadne nie wymaga programisty, większość to jeden przełącznik w panelu, a całość da się zrobić w godzinę.

Skąd biorą się włamania na WordPressa

WordPress napędza około czterdziestu procent stron w internecie, więc jest celem domyślnym – nie dlatego, że jest słaby, tylko dlatego, że jest wszędzie. Sam rdzeń jest dobrze pilnowany i łata się sam. Prawie wszystkie luki ujawniane w ekosystemie (według corocznych raportów Patchstack ponad 90 %) dotyczą wtyczek i motywów. Drugi wektor to logowanie: słabe hasło, brak drugiego składnika, nieograniczone próby. Trzeci – zaniedbana konfiguracja: edytor plików w panelu, katalog uploads wykonujący PHP, kopie zapasowe, których nikt nie sprawdził.

Dobra wiadomość: automat, który włamuje się do 10 000 stron dziennie, nie walczy z żadną konkretną. Jeśli Twoja strona nie ma trzech najczęstszych dziur, skrypt idzie dalej. Nie musisz być twierdzą – wystarczy, że nie jesteś najłatwiejszym celem na liście.

1. Automatyczne aktualizacje wtyczek i motywów

Gdzie: Wtyczki → zainstalowane → kolumna „Automatyczne aktualizacje” → włącz dla każdej; to samo w Wygląd → Motywy.

Rdzeń WordPressa aktualizuje się sam od lat (wydania poprawkowe od wersji 3.7, a nowe instalacje od 5.6 także wydania główne). Wtyczki i motywy – nie, dopóki tego nie włączysz. Tymczasem okno między publikacją łatki a masowym atakiem na niezałatane strony to często kilkanaście godzin. Włącz automatyczne aktualizacje dla wszystkiego, a wyjątki (np. wtyczka sklepu z własnymi modyfikacjami) aktualizuj ręcznie raz w tygodniu, nie „kiedyś”.

Druga połowa tego punktu: usuń nieużywane wtyczki i motywy, nie tylko je wyłącz. Pliki wyłączonej wtyczki nadal leżą na serwerze i nadal można je wywołać – dziura w nieaktywnej wtyczce jest wciąż dziurą. Zostaw jeden motyw zapasowy z rodziny Twenty, resztę skasuj.

2. Konto „admin” i widoczne loginy

Gdzie: Użytkownicy → Wszyscy.

Automaty próbują logować się na konta admin, administrator, test oraz na loginy, które same wyczytają ze strony. Jeśli masz użytkownika „admin”, załóż nowe konto administratora z innym loginem, zaloguj się na nie, a stare usuń (WordPress zapyta, komu przypisać treści – wybierz nowe konto).

WordPress ujawnia loginy w dwóch miejscach: w archiwum autora (adres /?author=1 przekierowuje na /author/twoj-login/) i w interfejsie REST (/wp-json/wp/v2/users). Ustaw każdemu użytkownikowi „Nazwę wyświetlaną” inną niż login, a na stronie firmowej bez bloga wieloautorskiego po prostu wyłącz archiwa autorów (większość wtyczek SEO ma taki przełącznik; Yoast: SEO → Wygląd w wyszukiwarce → Archiwa).

3. Silne hasła i drugi składnik logowania

Gdzie: Użytkownicy → Profil → Nowe hasło; wtyczka Two-Factor (rozwijana przez zespół WordPressa) albo moduł 2FA w Wordfence / WP 2FA.

Hasło do WordPressa to hasło do Twojej strony, Twojej listy klientów i – przez formularz – do ich zaufania. Wymagaj od siebie i od każdego administratora hasła z menedżera haseł (WordPress podpowiada silne przy zmianie) oraz drugiego składnika: kodu z aplikacji (Google Authenticator, Authy, 1Password) przy każdym logowaniu. Dla wygody wystarczy włączyć 2FA tylko dla ról Administrator i Redaktor.

Przy okazji przejrzyj role. Osoba, która pisze wpisy, nie potrzebuje konta administratora – wystarczy Autor albo Redaktor. Agencja, która skończyła projekt rok temu, nie potrzebuje konta w ogóle.

4. Limit prób logowania i wyłączony XML-RPC

Gdzie: wtyczka Limit Login Attempts Reloaded (albo moduł „Brute force” w Wordfence / Solid Security); XML-RPC – jedna linijka albo ta sama wtyczka.

Standardowy WordPress pozwala zgadywać hasło bez końca. Limit prób (np. 4 nieudane → blokada adresu IP na 20 minut) zamienia atak słownikowy z minut w lata. Druga furtka to plik xmlrpc.php – stary interfejs dla aplikacji mobilnej i Jetpacka. Jego metoda system.multicall pozwala sprawdzić setki haseł w jednym żądaniu, omijając zwykłe limity. Jeśli nie używasz aplikacji WordPress na telefonie ani Jetpacka, wyłącz go: w pliku functions.php motywu potomnego lub we wtyczce typu Code Snippets dodaj

add_filter( 'xmlrpc_enabled', '__return_false' );

albo zablokuj dostęp do xmlrpc.php na poziomie serwera / Cloudflare. Sprawdzisz w minutę: wejdź na twojadomena.pl/xmlrpc.php – jeśli widzisz „XML-RPC server accepts POST requests only”, jest włączony.

5. Kopia zapasowa poza serwerem – i jeden test odtworzenia

Gdzie: wtyczka UpdraftPlus / BackWPup / Duplicator; cel: Dysk Google, Dropbox, S3 – byle nie ten sam serwer.

Kopia zapasowa to jedyne zabezpieczenie, które działa po włamaniu. Trzy zasady: codziennie (baza danych) i co najmniej raz w tygodniu (pliki), poza serwerem (kopia w tym samym koncie hostingowym ginie razem ze stroną – przy włamaniu, awarii dysku i przy nieopłaconej fakturze), przetestowana: raz na kwartał odtwórz kopię na subdomenie testowej albo lokalnie. Kopia, której nikt nie próbował odtworzyć, to nadzieja, nie kopia. „Hosting robi backupy” nie zwalnia z tego punktu – to jego kopia, na jego warunkach, w jego terminach.

6. Wyłączony edytor plików w panelu

Gdzie: plik wp-config.php (przez FTP / menedżer plików hostingu), nad linią „That's all, stop editing!”.

define( 'DISALLOW_FILE_EDIT', true );

Domyślnie każdy administrator może w panelu (Wygląd → Edytor plików motywu) edytować kod PHP strony. To znaczy, że ktoś, kto zdobędzie hasło administratora – albo wykorzysta lukę w wtyczce dającą jego uprawnienia – w dwie minuty wgra tylne drzwi. Ta jedna linijka zabiera panelowi tę możliwość; kod nadal zmienisz przez FTP, czyli drugim, osobnym hasłem. Nikt na stronie firmowej nie edytuje PHP w przeglądarce, więc nic nie tracisz.

7. Uprawnienia plików i katalog uploads bez PHP

Gdzie: menedżer plików hostingu lub FTP; plik .htaccess w wp-content/uploads/.

Standard: katalogi 755, pliki 644, wp-config.php – 640 lub 600 (zależnie od hostingu; jeśli strona po zmianie pokazuje błąd, wróć do 644). Nigdy 777, nawet „na chwilę, bo wtyczka prosiła”. Druga rzecz: katalog uploads przyjmuje pliki z formularzy i z biblioteki mediów, więc to ulubione miejsce na podrzucony skrypt. Zabroń w nim wykonywania PHP – na Apache / LiteSpeed (większość polskich hostingów) plik wp-content/uploads/.htaccess z treścią:

<FilesMatch "\.(php|phtml|php[0-9])$">
Require all denied
</FilesMatch>

Przy okazji upewnij się, że serwer nie pokazuje listy plików w katalogach (wejdź na twojadomena.pl/wp-content/uploads/ – powinien być błąd 403, nie spis folderów). Jeśli widzisz spis, do głównego .htaccess dodaj Options -Indexes.

8. HTTPS wymuszony i nagłówki bezpieczeństwa

Gdzie: Ustawienia → Ogólne (oba adresy z https://); nagłówki – panel hostingu, Cloudflare albo .htaccess.

Certyfikat to dopiero początek. Oba adresy w ustawieniach WordPressa muszą zaczynać się od https://, inaczej część zasobów ładuje się nieszyfrowanie (mixed content), a logowanie potrafi iść otwartym tekstem. Potem nagłówki: HSTS, X-Content-Type-Options, X-Frame-Options, Referrer-Policy, Permissions-Policy – sześć linijek, które chronią Twoich klientów przed podmianą treści w otwartym Wi-Fi i osadzeniem Twojego panelu w cudzej ramce. Jak je włączyć bez psucia strony, opisaliśmy krok po kroku w tekście Nagłówki bezpieczeństwa HTTP po ludzku, a co jeszcze psuje się mimo kłódki – w HTTPS to nie wszystko.

9. Rejestracja wyłączona, komentarze pod kontrolą

Gdzie: Ustawienia → Ogólne → „Każdy może się zarejestrować”; Ustawienia → Dyskusja.

Na stronie firmowej nikt obcy nie powinien móc założyć konta. Odznacz „Każdy może się zarejestrować”, a „Domyślna rola nowego użytkownika” zostaw na Subskrybent – na wypadek, gdyby jakaś wtyczka znów to włączyła. Komentarze: jeśli nie prowadzisz bloga, wyłącz je globalnie (Dyskusja → odznacz „Zezwalaj na komentowanie nowych wpisów”) i zamknij na istniejących wpisach. Jeśli prowadzisz – „Komentarz musi zostać ręcznie zatwierdzony” plus Akismet. Spamowe komentarze z linkami to nie tylko bałagan: Google traktuje je jako Twoje linki wychodzące, a formularz komentarzy to kolejne miejsce, przez które wtyczki miewały luki.

10. Aktualne PHP i miesięczne spojrzenie w Stan witryny

Gdzie: panel hostingu → wersja PHP; w WordPressie Narzędzia → Stan witryny.

WordPress działa na PHP, a PHP ma daty ważności: wersja 8.1 przestała dostawać poprawki bezpieczeństwa z końcem 2025 r., 8.2 traci je z końcem 2026 r. Strona na starym PHP jest podatna na błędy, których nikt już nie naprawi – a przełączenie wersji w panelu hostingu to jedno kliknięcie (zrób kopię, przełącz na 8.3 lub nowszą, poklikaj po stronie; jeśli coś się wysypie, winna jest zwykle jedna stara wtyczka). Raz w miesiącu wejdź w Narzędzia → Stan witryny: WordPress sam wypisze nieaktywne motywy, stare PHP, brak HTTPS, wyłączone automatyczne aktualizacje i kilka innych rzeczy z tej listy.

Czego nie robić

• Nie instaluj trzech wtyczek bezpieczeństwa naraz. Jedna (Wordfence, Solid Security, SecuPress – dowolna porządna) wystarczy; dwie potrafią się blokować, a każda to kolejny kod do utrzymania.
• Nie zastępuj 2FA „ukryciem” adresu logowania. Zmiana /wp-login.php na /tajne-wejscie odsiewa najgłupsze boty, ale nie jest zabezpieczeniem – adres wycieka w linkach, e-mailach i w kodzie strony.
• Nigdy nie używaj „darmowych” płatnych motywów i wtyczek (tzw. nulled). Zdecydowana większość ma w środku tylne drzwi – to najprostszy sposób, żeby samemu zainstalować sobie włamanie.
• Nie ufaj zielonej kłódce. Certyfikat szyfruje połączenie. Nie łata wtyczek, nie pilnuje hasła, nie robi kopii.

Plan na godzinę

1. 0–10 min: aktualizacje automatyczne włączone, nieużywane wtyczki i motywy usunięte (1).
2. 10–25 min: nowe konto administratora, stare „admin” skasowane, role przejrzane, 2FA włączone (2, 3).
3. 25–35 min: wtyczka limitu logowań, XML-RPC wyłączony, rejestracja i komentarze ustawione (4, 9).
4. 35–50 min: kopia zapasowa poza serwer skonfigurowana i uruchomiona pierwszy raz (5).
5. 50–60 min: DISALLOW_FILE_EDIT, .htaccess w uploads, wersja PHP, adresy https w ustawieniach (6, 7, 8, 10).

Nagłówki bezpieczeństwa i test odtworzenia kopii zostaw na drugi wieczór – ale wpisz je do kalendarza, nie „na kiedyś”.