Zabezpieczenie WordPress w firmie zaczyna się od trzech rzeczy: aktualnych wtyczek, kont administratorów z drugim składnikiem logowania i kopii zapasowych poza serwerem. Reszta tej checklisty dokłada kolejne warstwy. Każdy punkt ma priorytet: 1 na ten tydzień, 2 na ten miesiąc, 3 na najbliższy przegląd.

Priorytety wynikają z tego, jak strony padają ofiarą ataków. Według raportu Patchstack za 2025 rok 91% nowych podatności dotyczyło wtyczek, a 9% motywów. W rdzeniu WordPressa zgłoszono 6 luk, wszystkie o niskim priorytecie.

Większość punktów przejdziesz sam z kontem administratora i dostępem do panelu hostingu. Zmiany w wp-config.php i uprawnieniach plików wymagają dostępu SFTP lub SSH.

Priorytet 1: aktualizacje

  • Sprawdź, czy drobne wydania rdzenia (np. z 7.1.1 do 7.1.2) instalują się automatycznie. WordPress robi to domyślnie, chyba że ktoś wyłączył tę funkcję w wp-config.php stałą AUTOMATIC_UPDATER_DISABLED lub WP_AUTO_UPDATE_CORE.
  • Poprawki bezpieczeństwa wtyczek instaluj w ciągu doby od wydania.
  • Pozostałe aktualizacje przeglądaj raz w tygodniu.
  • Duże aktualizacje motywu, WooCommerce lub page buildera testuj najpierw na kopii strony. Jak to zrobić bez przestoju, opisujemy w poradniku o aktualizacjach WordPress bez awarii.
  • Sprawdź wersję PHP w panelu hostingu. Według php.net PHP 8.1 nie dostaje już poprawek, a 8.2 dostaje je tylko do 31 grudnia 2026 r.

Zwłoka kosztuje. Patchstack podaje, że mniej więcej połowa luk o wysokim wpływie była atakowana w ciągu 24 godzin od ujawnienia.

Priorytet 1: konta, hasła i 2FA

  • Wypisz wszystkie konta z rolą administratora i przypisz każde do konkretnej osoby.
  • Usuń konta byłych pracowników, poprzedniej agencji i freelancerów. Przy usuwaniu przepisz ich treści na inne konto.
  • Włącz drugi składnik logowania (2FA) dla administratorów i kierowników sklepu. WordPress 7.1 nadal nie ma go w rdzeniu, więc dodaje go wtyczka, np. Two Factor z oficjalnego katalogu wordpress.org.
  • Nadawaj najniższą rolę, która wystarcza do pracy. Osoba pisząca wpisy potrzebuje roli Autor lub Redaktor, obsługa zamówień w WooCommerce roli Kierownik sklepu.
  • Przejrzyj hasła aplikacji w profilach użytkowników. Służą do logowania przez API z pominięciem formularza, więc omijają też 2FA. Usuń te, których nikt nie rozpoznaje.
  • Każdy pracuje na własnym koncie. Wspólne konto „biuro” uniemożliwia sprawdzenie, kto co zmienił.
  • Jeśli nadal istnieje konto o loginie „admin”, załóż nowe konto administratora i usuń stare. Boty zgadują ten login w pierwszej kolejności.
  • Hasła trzymaj w menedżerze haseł. Arkusz w chmurze i stary mail to pierwsze miejsca, które przegląda ktoś z dostępem do skrzynki.

Przy przejmowaniu strony od innego wykonawcy ten punkt robisz pierwszego dnia. Listę dostępów do odzyskania zebraliśmy w tekście o przejęciu strony WordPress od agencji.

Priorytet 1: kopie zapasowe z testem odtworzenia

  • Kopia plików i bazy codziennie. Sklep z wieloma zamówieniami dziennie potrzebuje kopii bazy kilka razy na dobę.
  • Co najmniej jedna kopia poza serwerem strony i poza kontem hostingowym. Kopię na tym samym serwerze atakujący zaszyfruje albo usunie razem ze stroną.
  • Przechowywanie przez co najmniej 30 dni. Włamanie często wychodzi na jaw po tygodniach, więc wczorajsza kopia bywa już zainfekowana.
  • Osobne dane dostępowe do archiwum kopii. Hasło do panelu WordPress nie może otwierać kopii.
  • Dodatkowa kopia bazy przed każdą większą aktualizacją, niezależnie od harmonogramu.
  • Test odtworzenia raz na kwartał na osobnej kopii strony.

Kopia, której nikt nie odtworzył, to tylko hipoteza.

Priorytet 2: wtyczki i motyw

  • Usuń wyłączone wtyczki i nieużywane motywy. Ich pliki zostają na serwerze i atakujący może wywołać je bezpośrednio.
  • Przy każdej wtyczce sprawdź datę ostatniej aktualizacji w katalogu wordpress.org. Brak nowej wersji od ponad roku to sygnał, żeby szukać zamiennika.
  • Sprawdź, czy któraś wtyczka nie zniknęła z katalogu. Strona zamkniętej wtyczki pokazuje komunikat o zamknięciu, a jednym z powodów bywa niezałatana luka.
  • Przed instalacją nowej wtyczki sprawdź liczbę aktywnych instalacji, datę ostatniej wersji i to, czy autor odpowiada na forum wsparcia.
  • Usuń motywy i wtyczki z nieoficjalnych źródeł („nulled”). Kup licencję albo znajdź zamiennik.
  • Sprawdź, czy licencje wtyczek premium są aktywne i przypisane do firmy, a nie do poprzedniej agencji. Wygasła licencja zwykle oznacza brak aktualizacji.
  • Jeśli motyw od lat nie dostaje aktualizacji, zaplanuj jego wymianę. Koszty obu dróg porównujemy w tekście motyw dedykowany czy gotowy.

Liczba wtyczek sama w sobie nie przesądza o ryzyku. Liczy się to, czy każda ma aktywnego autora i kogoś, kto ją aktualizuje.

Priorytet 2: logowanie, XML-RPC i firewall

  • Ogranicz liczbę prób logowania. WordPress domyślnie nie blokuje zgadywania haseł, więc robi to wtyczka, serwer albo firewall.
  • Zablokuj plik xmlrpc.php, jeśli nic z niego nie korzysta. Pozwala sprawdzić wiele haseł w jednym zapytaniu. Przed blokadą upewnij się, że nie używa go żadna aplikacja mobilna ani wtyczka, np. Jetpack.
  • Dopisz w wp-config.php linię define( 'DISALLOW_FILE_EDIT', true );. Wyłącza edytor plików motywu i wtyczek w panelu.
  • Ustaw uprawnienia plików według podręcznika hardeningu WordPress: katalogi 755, pliki 644, wp-config.php 400 lub 440.
  • Postaw firewall aplikacyjny (WAF) przed serwerem, na poziomie CDN, albo jako wtyczkę. Firewall przed serwerem odcina złośliwy ruch, zanim uruchomi PHP.

Nie zakładaj, że hosting zrobi to za Ciebie. W testach opisanych przez Patchstack zabezpieczenia hostingów zablokowały tylko 26% prób wykorzystania luk.

Priorytet 3: logi i monitoring

  • Log aktywności w panelu: kto się logował, kto zmienił wtyczki, kto założył konto.
  • Logi serwera, czyli dostępu i błędów, trzymane co najmniej 30 dni. Zapytaj hosting, ile przechowuje je domyślnie.
  • Powiadomienie e-mail o nowym koncie administratora i o zmianie plików rdzenia.
  • Monitoring dostępności co kilka minut, z alertem SMS lub w komunikatorze.
  • Regularne skanowanie plików pod kątem złośliwego kodu i porównanie rdzenia z sumami kontrolnymi (wp core verify-checksums).
  • Google Search Console podpięte do firmowej skrzynki. Tam Google zgłasza wykryte włamania.

Logi niczego nie blokują. Pokazują za to, którędy ktoś wszedł, gdy do włamania już dojdzie. Co robić wtedy godzina po godzinie, opisaliśmy w poradniku włamanie na stronę WordPress: co zrobić.

Alert ma sens tylko wtedy, gdy ktoś go czyta. Ustal, kto w firmie odbiera powiadomienia i kto go zastępuje na urlopie.

Priorytet 3: hosting i serwer

  • Każda strona na osobnym koncie hostingowym. Jedna zaniedbana strona na wspólnym koncie zaraża pozostałe.
  • SFTP lub SSH zamiast zwykłego FTP, który przesyła hasło otwartym tekstem.
  • HTTPS na całej stronie, z przekierowaniem z HTTP.
  • Wspierana wersja PHP i bazy danych. WordPress zaleca PHP 8.3 lub nowsze oraz MySQL 8.0 lub MariaDB 10.11.
  • Kopie robione przez hosting traktuj jako drugą warstwę, obok własnych.

Na co jeszcze patrzeć przy wyborze serwera, piszemy w tekście o hostingu dla WordPress i WooCommerce.

Co daje mniej, niż obiecuje

Kilka popularnych porad zajmuje czas, a ochrony dodaje niewiele:

  • Zmiana adresu logowania z /wp-admin. Zmniejsza szum w logach, ale nie zastępuje 2FA ani limitu prób.
  • Zmiana prefiksu tabel na działającej stronie. Podręcznik WordPressa ją wymienia, ale na istniejącej instalacji łatwo przy tym uszkodzić bazę.
  • Ukrywanie numeru wersji WordPressa. Boty i tak próbują znanych luk na ślepo.
  • Wtyczka bezpieczeństwa zainstalowana i zostawiona z domyślnymi ustawieniami. Sprawdź po instalacji, czy 2FA i firewall są włączone i na czyj adres idą alerty.
  • Kilka wtyczek bezpieczeństwa naraz. Dublują funkcje, spowalniają panel i potrafią blokować się nawzajem.

Najczęstsze pytania

Czy darmowa wtyczka bezpieczeństwa wystarczy dla firmowej strony?

Jako jedna z warstw tak. Darmowe wersje popularnych wtyczek dają limit logowań, 2FA i skanowanie plików. Nie zastąpią aktualizacji, kopii poza serwerem ani osoby, która czyta ich powiadomienia. Typowy problem to alerty wysyłane na skrzynkę, której nikt nie otwiera.

Jak często aktualizować WordPress i wtyczki?

Poprawki bezpieczeństwa instaluj w ciągu doby od wydania. Pozostałe aktualizacje przeglądaj raz w tygodniu. Drobne wydania rdzenia WordPress instaluje sam, jeśli nikt tego nie wyłączył. Duże aktualizacje, np. WooCommerce albo motywu, sprawdzaj najpierw na kopii strony.

Czy WordPress jest mniej bezpieczny niż inne systemy?

Sam rdzeń WordPressa ma mało luk: w 2025 roku Patchstack odnotował w nim 6, wszystkie o niskim priorytecie. Pozostałe z 11 334 zgłoszonych podatności dotyczyły wtyczek i motywów. Bezpieczeństwo strony zależy więc głównie od tego, jakie wtyczki masz i jak szybko ktoś je aktualizuje.

Od czego zacząć, jeśli strona nie była aktualizowana od roku?

Od pełnej kopii zapasowej zapisanej poza serwerem, a dopiero potem od aktualizacji. Po długiej przerwie aktualizacje często psują motyw lub wtyczki, więc rób je na kopii strony. Równolegle przejrzyj konta administratorów i usuń te, których nie rozpoznajesz.

Każdą stronę, którą przejmujemy w stałej opiece WordPress, zaczynamy od audytu technicznego. Potem aktualizacje testujemy na kopii strony, a kopie trzymamy w trzech lokalizacjach geograficznych. Do tego dochodzą skanowanie malware, hardening i monitoring dostępności 24/7.