Bezpieczeństwo WordPressa: lista kontrolna dla firm w UE (2026)

Ta lista kontrolna bezpieczeństwa WordPressa obejmuje 25 środków, które zalecamy każdej firmowej stronie internetowej w UE. Podzieliliśmy je na sześć obszarów: hosting, oprogramowanie WordPress, konta, monitoring, kopie zapasowe i dokumentację. Najlepiej przechodzić je od góry do dołu: pierwsze trzy grupy zapobiegają większości ataków, a trzy ostatnie pomagają zauważyć incydent, przywrócić stronę i wykazać, co zostało zrobione.

Każdy punkt ma jednozdaniowe uzasadnienie, a tam, gdzie to potrzebne, odnośnik do szczegółowego poradnika. Żadna lista nie sprawi, że strona będzie „w 100% bezpieczna”, ale ta zapewnia poziom ochrony, który można rzeczowo uzasadnić przed klientem, audytorem czy organem nadzorczym.

Dlaczego liczy się czas: firma Patchstack, dostawca rozwiązań bezpieczeństwa, naliczyła w 2025 roku 11 334 nowe podatności w ekosystemie WordPressa, z czego 91% dotyczyło wtyczek. Około połowa podatności o dużym wpływie była wykorzystywana przez atakujących w ciągu 24 godzin (Patchstack, State of WordPress Security in 2026, raport producenta). Stała rutyna daje więcej niż jakiekolwiek pojedyncze narzędzie.

Hosting i serwer

Jeśli serwer jest słabo zabezpieczony, żadne ustawienia w samym WordPressie w pełni tego nie zrekompensują.

• HTTPS na każdej podstronie, a potem HSTS. HTTPS szyfruje dane logowania, treść formularzy i zamówienia podczas przesyłania, a art. 32 ust. 1 lit. a RODO wprost wymienia szyfrowanie. Nagłówek HSTS (RFC 6797) warto dodać dopiero wtedy, gdy HTTPS działa wszędzie, i zacząć od krótkiego max-age: przez ten czas przeglądarki odmawiają połączeń przez zwykłe HTTP.
• Wspierana wersja PHP. Gałęzie PHP, których wsparcie się zakończyło, nie dostają już poprawek bezpieczeństwa; używaną wersję warto porównać z oficjalną listą.
• SFTP lub SSH zamiast FTP oraz osobne, odizolowane konto dla każdej strony. FTP przesyła hasła bez szyfrowania, a bez izolacji jedna zhakowana strona może zainfekować wszystkie pozostałe na tym samym koncie.
• Zakaz wykonywania PHP w katalogu uploads. Ten katalog powinien zawierać wyłącznie media; plik PHP w tym miejscu to niemal zawsze web shell.

W Apache 2.4 należy umieścić w pliku wp-content/uploads/.htaccess:

<FilesMatch "\.(?i:php|phtml|phar)$">
    Require all denied
</FilesMatch>

W nginx regułę dodaje się do bloku server, nad ogólnym blokiem location ~ \.php$ (wygrywa pierwsza pasująca lokalizacja z wyrażeniem regularnym):

location ~* ^/wp-content/uploads/.*\.(php|phtml|phar)$ {
    deny all;
}

Przed przeładowaniem nginx trzeba sprawdzić konfigurację poleceniem nginx -t. Niezależnie od serwera warto potem upewnić się, że obrazy nadal się wczytują, a testowy plik .php w katalogu uploads zwraca „403 Forbidden”.

Rdzeń WordPressa, wtyczki i motywy

Najwięcej podatności kryje się we wtyczkach, dlatego ta grupa wymaga cotygodniowej rutyny. Więcej na ten temat piszemy w poradniku o podatnych wtyczkach WordPress.

• Włączone automatyczne aktualizacje bezpieczeństwa rdzenia. Domyślnie WordPress instaluje w tle wydania pomocnicze (minor), które zawierają poprawki bezpieczeństwa. Trzeba się upewnić, że nie wyłączyło ich żadne ustawienie ani narzędzie firmy hostingowej.
• Aktualizacje wtyczek i motywów w ciągu dni, a nie miesięcy. W przypadku najintensywniej atakowanych podatności Patchstack zmierzył ważoną medianę pięciu godzin do masowego wykorzystania. Automatyczne aktualizacje, dostępne od WordPressa 5.5, skracają to opóźnienie przy wtyczkach o niskim ryzyku.
• Usunięcie wszystkiego, co nie jest używane. Pliki dezaktywowanej wtyczki zostają na serwerze i nadal mogą stanowić furtkę dla atakującego; polecenie wp plugin list --status=inactive wskaże kandydatów do usunięcia.
• Wymiana porzuconych wtyczek i żadnych kopii „nulled”. W danych Patchstacka 46% podatności nie miało poprawki w chwili ujawnienia. Porzucona wtyczka może jej nigdy nie dostać, a piracka kopia nie otrzymuje żadnych aktualizacji.
• Wyłączony edytor plików w kokpicie. define( 'DISALLOW_FILE_EDIT', true ); w pliku wp-config.php usuwa edytory plików motywów i wtyczek, więc ktoś, kto przejmie konto administratora, nie wklei po prostu kodu do pliku motywu.

Konta i logowanie

Administrator może instalować wtyczki, a więc uruchamiać kod na serwerze. Domyślne role (Administrator, Redaktor, Autor, Współpracownik, Subskrybent) ułatwiają stosowanie zasady minimalnych uprawnień.

• Unikalne hasła i uwierzytelnianie dwuskładnikowe dla każdego Administratora i Redaktora. Ataki typu credential stuffing wykorzystują właśnie hasła, które wyciekły i były używane w wielu miejscach. Rdzeń WordPressa nie ma wbudowanego 2FA; dostępne rozwiązania opisujemy w poradniku o uwierzytelnianiu dwuskładnikowym.
• Jedno imienne konto na osobę, z najniższą rolą, która wystarcza do pracy. Wspólne loginy „dla agencji” ukrywają, kto co zrobił, i nie da się ich w uporządkowany sposób odebrać.
• Usunięcie starych kont i nieużywanych haseł aplikacji. Byli pracownicy i agencje zachowują dostęp, dopóki ktoś go nie usunie; hasła aplikacji (od WordPressa 5.6) są widoczne w profilu każdego użytkownika.
• Ograniczenie prób logowania i wyłączenie XML-RPC, jeśli nic z niego nie korzysta. XML-RPC jest domyślnie włączony i przyjmuje hasła z pominięciem zwykłego formularza logowania. Najpierw trzeba sprawdzić, czy jakaś wtyczka lub aplikacja nadal go potrzebuje.

Monitoring i wykrywanie

Termin 72 godzin na zgłoszenie naruszenia da się dotrzymać tylko wtedy, gdy w ogóle się je zauważy.

• Regularne skanowanie pod kątem złośliwego oprogramowania i integralności plików. Nowe pliki PHP w katalogu uploads, zmienione pliki rdzenia i zaciemniony kod to typowe ślady włamania. Polecenie wp core verify-checksums porównuje pliki rdzenia z oficjalnymi sumami kontrolnymi WordPress.org. Zob. też 12 oznak, że strona została zhakowana.
• Dzienniki aktywności i alerty o nowych administratorach. Ukryte konta administratorów to częsty sposób, w jaki atakujący utrzymują dostęp. Logi pomagają odtworzyć przebieg incydentu; trzeba jednak ustalić okres ich przechowywania, bo zawierają adresy IP.
• Powiadomienia o podatnościach we wtyczkach, które faktycznie działają na stronie. Baza podatności, np. WPScan lub Patchstack, informuje, gdy w którejś z używanych wtyczek wykryto znany problem.
• Google Search Console i monitoring dostępności. Search Console zgłasza wykryte przez Google problemy z bezpieczeństwem strony, np. wstrzyknięty spam; monitoring dostępności wychwytuje awarie.

Wtyczka Security Audit & Compliance od secaudit.eu automatyzuje część tych kontroli: integralność plików, sygnatury złośliwego oprogramowania, ukrytych administratorów, nieaktualne wtyczki, słabe hasła i ustawienia zabezpieczeń, a swoje wyniki przypisuje do art. 32 RODO i art. 21 NIS2.

Kopie zapasowe i przywracanie

Art. 32 ust. 1 lit. c RODO wymaga zdolności do szybkiego przywrócenia dostępności danych osobowych i dostępu do nich w razie incydentu. Tę obietnicę spełniają tylko przetestowane kopie zapasowe.

• Automatyczne kopie plików i bazy danych, przy aktywnych stronach co najmniej raz dziennie. Zamówienia i wpisy z formularzy przybywają każdego dnia; kopia sprzed tygodnia ich nie zawiera.
• Co najmniej jedna kopia poza serwerem i poza zasięgiem strony. Archiwum kopii w katalogu głównym strony może pobrać każdy, kto odgadnie jego nazwę, a kopię, którą może usunąć sama strona, może usunąć także atakujący.
• Test przywracania co najmniej dwa razy w roku. Kopia, której nigdy nie przywrócono, to nadzieja, a nie plan, a art. 32 ust. 1 lit. d wymaga regularnego testowania stosowanych środków.
• Jednostronicowy plan reagowania na incydenty. Kto podejmuje decyzje, kto dzwoni do firmy hostingowej, gdzie są czyste kopie zapasowe i jak zgłosić naruszenie ochrony danych w ciągu 72 godzin. Samo czyszczenie strony opisuje nasz plan usuwania złośliwego oprogramowania.

Dokumentacja i zgodność z przepisami

Zgodnie z art. 5 ust. 2 RODO trzeba umieć wykazać stosowane środki. Wystarczą krótkie, datowane zapisy.

• Wykaz wtyczek, motywów, usług zewnętrznych i dostępów. Nie da się załatać ani sprawdzić czegoś, o czym się nie wie. Na liście powinny się znaleźć także zapytania do zewnętrznych serwerów, np. Google Fonts ładowane z serwerów Google.
• Umowy powierzenia przetwarzania danych z dostawcą hostingu i agencją. Każdy, kto przetwarza dane osobowe w Państwa imieniu – także agencja z dostępem administratora – potrzebuje takiej umowy na podstawie art. 28 RODO.
• Rejestr naruszeń i incydentów. Art. 33 ust. 5 RODO wymaga dokumentowania każdego naruszenia ochrony danych osobowych, również tych, których nie trzeba było zgłaszać.
• Datowane dowody, przeglądane co najmniej raz w roku. Dzienniki aktualizacji, raporty ze skanowania i protokoły testów przywracania pokazują, że środki rzeczywiście działają.

Jak lista kontrolna bezpieczeństwa WordPressa odpowiada RODO i NIS2

Art. 32 ust. 1 RODO wymaga odpowiednich środków technicznych i organizacyjnych z uwzględnieniem stanu wiedzy technicznej, kosztów wdrożenia i ryzyka. Art. 21 ust. 2 dyrektywy NIS2 wymienia dziesięć minimalnych środków dla podmiotów objętych jej zakresem.

Dyrektywa NIS2 obejmuje przede wszystkim średnie i duże przedsiębiorstwa z wymienionych w niej sektorów, a szczegóły różnią się w poszczególnych państwach, dlatego trzeba sprawdzić krajowe przepisy wdrażające NIS2. Mniejsi dostawcy odczuwają ją pośrednio, ponieważ podmioty objęte dyrektywą muszą zarządzać bezpieczeństwem łańcucha dostaw i oczekują od dostawców dowodów. Więcej piszemy w artykułach o art. 32 RODO i zakresie NIS2. Firmy sprzedające wtyczki lub motywy mają ponadto obowiązki producenta wynikające z Cyber Resilience Act (CRA, akt w sprawie cyberodporności).

Najczęstsze pytania

Jak często należy przechodzić tę listę?

Zalecamy pełny przegląd co najmniej raz w roku oraz po każdej większej zmianie, np. zmianie firmy hostingowej lub agencji.

Czy po odhaczeniu wszystkich punktów strona jest zgodna z RODO?

Żadna lista kontrolna sama tego nie zapewni. Art. 32 opiera się na ocenie ryzyka: sklep z kontami klientów potrzebuje więcej niż prosta strona wizytówka. Lista obejmuje techniczne minimum, a dokumentacja wyjaśnia, dlaczego jest ono adekwatne do Państwa ryzyka.

Mamy tylko małą stronę wizytówkę. Czy to nas dotyczy?

W większości tak. Zautomatyzowane ataki nie biorą pod uwagę wielkości firmy, a RODO ma zastosowanie, gdy tylko formularz kontaktowy zbiera dane osobowe.

Ten artykuł ma charakter ogólnoinformacyjny i nie stanowi porady prawnej.