🔒 Bezpieczeństwo WordPress w 2026 roku: pełny przewodnik po ochronie strony

Сервер WordPress nie zostaje zhakowany dlatego, że silnik jest „dziurawy". Zostaje zhakowany dlatego, że właściciel odłożył aktualizację wtyczki, ustawił hasło admin123 i nie wyłączył xmlrpc.php. Zautomatyzowane boty skanują internet bez przerwy.

Nie obchodzi ich, czy sprzedaje Pan/Pani ręcznie robione świece, czy prowadzi sklep internetowy. Lukę znajdą i wykorzystają. Brutalne łamanie loginów, SQL injection, wrzucenie shella przez dziurawą wtyczkę, wszystko to trwa całą dobę.

Dobra wiadomość: podstawową ochronę można zbudować w jeden wieczór, bez głębokiej wiedzy technicznej. Poniżej sprawdzony zestaw działań: od instalacji zapory po ręczne hartowanie serwera. Wszystko, co opisano, stosujemy na swoich projektach.

💡 Szybki przegląd:

• Proszę zainstalować zaporę: BBQ lub Wordfence, pierwsza linia obrony blokuje większość ataków jeszcze przed WordPressem.
• Proszę zamknąć typowe punkty wejścia: xmlrpc.php, REST API dla niezalogowanych, listing katalogów, edytor plików w panelu administracyjnym.
• Proszę skonfigurować automatyczne aktualizacje rdzenia, motywów i wtyczek. Nieaktualna wersja wtyczki to główny wektor włamania.
• Proszę zrobić kopię zapasową, która jest przechowywana POZA serwerem. Bez kopii zapasowej odzyskiwanie po włamaniu to ponowna instalacja WordPressa od zera.
• Proszę włączyć uwierzytelnianie dwuskładnikowe dla wszystkich administratorów. Hasło można złamać, drugiego składnika, nie.

Gdzie uderzają w pierwszej kolejności: typowe wektory ataków

Większość wyobraża sobie hakera jako osobę przed terminalem, która ręcznie próbuje odgadnąć hasło do panelu administracyjnego. Rzeczywistość jest nudniejsza: praktycznie wszystkie ataki wykonują boty według skryptu. Szukają znanych luk we wtyczkach i motywach, dobijają się do xmlrpc.php, skanują /wp-content/uploads/ w poszukiwaniu wykonywalnych plików PHP.

Główne wektory ataków na WordPress:

• Nieaktualne wtyczki i motywy. Według raportów Sucuri około 40% zhakowanych witryn w momencie infekcji używało nieaktualnej wersji CMS, wtyczki lub motywu. Deweloperzy zamykają dziury łatkami, ale tylko wtedy, gdy Pan/Pani te łatki zastosuje.

• Słabe hasła. Ataki brute-force sprawdzają dziesiątki tysięcy kombinacji na minutę. Hasło składające się z 6 znaków bez znaków specjalnych zostaje złamane natychmiast.

• Niebezpieczny hosting. Tani hosting współdzielony oszczędza na izolacji kont: jeśli sąsiednia strona na serwerze zostanie zhakowana, atak może przenieść się na Pana/Pani witrynę.

• Zerowe prawa do zapisu. Gdy serwer WWW może zapisywać dane w dowolnym pliku, wgrany przez lukę shell uzyskuje pełną kontrolę nad stroną.

Zrozumienie tych wektorów to połowa ochrony. Drugą połową są konkretne działania.

Poziom 1: szybka ochrona, którą zainstaluje Pan/Pani w pół godziny

Od tego warto zacząć jeszcze dziś. Każda czynność zajmuje minuty, nie wymaga edycji kodu i nie uszkodzi strony.

Proszę zainstalować zaporę: BBQ Firewall

BBQ Firewall to wtyczka Jeffa Starra, która działa na zasadzie „zainstaluj i zapomnij". Żadnych ustawień, żadnej ingerencji w .htaccess ani w bazę danych. Po prostu blokuje szkodliwe zapytania URL, zanim dotrą do WordPressa: eval(), base64_decode, nadmiernie długie ciągi znaków, próby iniekcji.

Wtyczka waży mniej niż 10 KB i nie generuje obciążenia. Przy tym wyłapuje SQL injection, XSS, wgrywanie plików wykonywalnych oraz ataki przez „złych" odsyłaczy.

W praktyce BBQ często instaluje się NA WIERZCH Wordfence lub Solid Security, rozwiązują one różne zadania i nie kolidują ze sobą. Zapora na poziomie zapytań plus pełnowartościowa wtyczka bezpieczeństwa dają ochronę warstwową.

Proszę włączyć uwierzytelnianie dwuskładnikowe

Hasło można złamać, przechwycić lub kupić w zrzucie wyciekłych baz danych. Drugi składnik, jednorazowy kod z aplikacji uwierzytelniającej, psuje całą matematykę brute-force.

Wbudowanego 2FA w WordPressie nie ma. Najprostsza droga to zainstalować Solid Security (dawniej iThemes Security) lub Wordfence. Oba zawierają 2FA w wersji darmowej. Po aktywacji proszę wejść w Security → Settings → Two-Factor Authentication i włączyć dla roli Administrator.

Te same wtyczki zamykają jeszcze kilkanaście luk „od ręki":

• Solid Security: zmienia URL logowania (/wp-admin → Pana/Pani unikalny), ustawia limit prób logowania, skanuje pliki pod kątem zmian, blokuje IP po serii nieudanych logowań, sprawdza wtyczki i motywy pod kątem znanych luk.

• Wordfence: Web Application Firewall z automatycznie aktualizowanymi regułami, skaner złośliwego kodu, ochrona przed brute-force, monitorowanie ruchu w czasie rzeczywistym. Szczególnie dobry do czyszczenia już zhakowanej strony: znajduje backdoory, zmienione pliki rdzenia, ukryty spam.

Wystarczy JEDNA z nich. My na swoich projektach instalujemy Wordfence + BBQ: pierwszy daje WAF i skaner, drugi odcina śmieciowe zapytania jeszcze na podejściu.

Proszę wyłączyć xmlrpc.php

XML-RPC to interfejs do zdalnej pracy z WordPressem przez aplikacje mobilne i trackbacki. Dziś nie jest potrzebny zdecydowanej większości stron, ale pozostaje jednym z najczęściej atakowanych punktów: przez xmlrpc.php boty łamią hasła metodą brute-force i przeprowadzają ataki DDoS.

Wyłączyć można na dwa sposoby. Szybki, przez wtyczkę: Solid Security robi to jednym kliknięciem. Właściwy, na poziomie serwera, w .htaccess:

1
<Files xmlrpc.php>
2
Order Deny,Allow
3
Deny from all
4
</Files>

Proszę dodać ten blok do głównego pliku .htaccess i zapomnieć o xmlrpc. Jeśli korzysta Pan/Pani z aplikacji mobilnej WordPress lub zewnętrznych serwisów, które potrzebują XML-RPC, proszę najpierw sprawdzić, czy działają bez niego. W 2026 roku alternatywy, REST API z uwierzytelnianiem, pokrywają prawie wszystkie scenariusze.

Proszę wyłączyć listing katalogów

Proszę otworzyć w przeglądarce вашсайт.com/wp-content/uploads/. Jeśli widzi Pan/Pani listę plików, ma Pan/Pani problem. Listing katalogów pokazuje strukturę strony każdemu, kto zechce.

Rozwiązanie: jedna linijka w .htaccess:

1
Options -Indexes

Przy okazji proszę dodać pusty plik index.php w każdym podejrzanym katalogu: /wp-content/uploads/, motywy, wtyczki bez własnego index.php.

Proszę wyłączyć edytor plików w panelu administracyjnym

WordPress domyślnie pozwala edytować pliki .php motywów i wtyczek bezpośrednio z panelu administracyjnego: Wygląd → Edytor plików motywu oraz Wtyczki → Edytor plików wtyczek. To wygodne, dopóki do panelu nie dostanie się osoba niepowołana. Wtedy staje się to gotowym narzędziem do wgrania shella.

Proszę dodać w wp-config.php jedną stałą:

1
define('DISALLOW_FILE_EDIT', true);

To wszystko. Edytor znika z panelu administracyjnego. Do edycji plików proszę używać FTP/SFTP, jest to mniej wygodne, ale bezpieczniejsze.

Poziom 2: ręczne hartowanie WordPressa

Kolejne działania są nieco głębsze: wymagają edycji plików konfiguracyjnych i zrozumienia struktury serwera. Rezultat, witryna, którą boty omijają, bo nie widzą w niej WordPressa.

Proszę zaktualizować sole bezpieczeństwa

Sole, security keys i salts, to osiem ciągów w wp-config.php, które szyfrują ciasteczka uwierzytelniające. Ich zmiana oznacza natychmiastowe wylogowanie wszystkich, w tym potencjalnego intruza z przechwyconą sesją.

Proszę przejść na api.wordpress.org/secret-key/1.1/salt/, skopiować wygenerowany blok i zastąpić nim odpowiedni fragment w wp-config.php. Zajmuje to minutę. Proszę to robić za każdym razem, gdy istnieje podejrzenie kompromitacji.

Proszę zmienić prefiks tabel bazy danych

Domyślnie wszystkie tabele WordPressa nazywają się wp_posts, wp_users i wp_options. Ataki SQL injection są często przygotowane właśnie pod standardowy prefiks.

Podczas świeżej instalacji proszę wskazać niestandardowy prefiks w wp-config.php:

1
$table_prefix = 'wp83x_';

W przypadku istniejącej witryny zmiana jest trudniejsza: trzeba zmienić nazwy tabel w bazie danych i zaktualizować wartości w usermeta oraz options. Bez pewnego opanowania phpMyAdmin i SQL proszę się za to nie zabierać, ryzyko zawalenia witryny jest zbyt wysokie.

Proszę przenieść wp-config.php powyżej katalogu głównego

wp-config.php zawiera hasło do bazy danych i klucze szyfrujące. Jeśli serwer WWW omyłkowo udostępni go jako tekst, a zdarza się to podczas nieudanej aktualizacji PHP, intruz otrzymuje wszystko.

Rozwiązanie: proszę przenieść wp-config.php o jeden poziom wyżej niż katalog główny witryny, na przykład z /public_html/ do folderu domowego hostingu. WordPress automatycznie szuka pliku konfiguracyjnego w katalogu nadrzędnym, kod się nie uszkodzi.

Proszę ukryć wersję WordPressa

Generator <meta name="generator" content="WordPress X.X.X"> w kodzie źródłowym strony to prezent dla botów. Porównują one wersję z bazą znanych podatności i uderzają precyzyjnie.

Proszę usunąć generator przez functions.php:

1
// Видаляємо мета-тег генератора WordPress з вихідного коду сторінки
2
function no_generator() {
3
    return '';
4
}
5
add_filter('the_generator', 'no_generator');

Funkcja no_generator() zwraca pusty ciąg zamiast standardowego wyświetlania wersji. Filtr the_generator przechwytuje wyjście metatagu i wszystkich jego wariantów dla kanałów, RSS i REST API.

Przy okazji proszę usunąć readme.html i liesmich.html z katalogu głównego instalacji, one również ujawniają wersję. Po aktualizacji WordPressa pliki te mogą pojawić się ponownie, proszę sprawdzać raz w miesiącu.

Proszę skonfigurować HTTP Security Headers

Nagłówki HTTP odpowiedzi serwera informują przeglądarkę, jak ma postępować z treścią. Prawidłowo skonfigurowane security headers blokują clickjacking, XSS i podmianę treści.

Minimalny zestaw dla WordPressa, proszę dodać te linie do .htaccess:

1
Header set X-Frame-Options "SAMEORIGIN"
2
Header set X-Content-Type-Options "nosniff"
3
Header set Referrer-Policy "strict-origin-when-cross-origin"
4
Header set X-XSS-Protection "1; mode=block"

Wtyczka HTTP Headers umożliwia zrobienie tego samego przez panel administracyjny, jeśli nie chcą Państwo dotykać konfiguracji serwera.

Do zaawansowanej konfiguracji proszę użyć Content Security Policy. Proszę jednak wziąć pod uwagę: nieprawidłowy CSP psuje panel administracyjny, ładowanie czcionek i działanie wtyczek. Proszę wprowadzać stopniowo, zaczynając od trybu Content-Security-Policy-Report-Only.

Proszę ograniczyć uprawnienia do plików

Uprawnienia dostępu to ostatnia linia obrony. Jeśli intruz wgrał plik, ale nie może go wykonać, atak się załamał.

Podstawowe zasady:

• Katalogi: 755, właściciel czyta, zapisuje, wykonuje; grupa i pozostali czytają i wykonują.
• Pliki: 644, właściciel czyta i zapisuje, pozostali tylko czytają.
• wp-config.php: 400, tylko właściciel czyta.
• .htaccess: 444, tylko odczyt dla wszystkich, jeśli WordPress nie edytuje go automatycznie.

Proszę kategorycznie unikać 777. Tak, niektóre wtyczki proszą o 777 na wp-content/uploads/. Proszę nie dawać. 755 na folder i 644 na pliki wewnątrz wystarcza do przesyłania plików multimedialnych.

Co robić, jeśli witryna została już zhakowana

Włamanie wykrywa się na różne sposoby: przekierowanie na kasyno, wysyłanie spamu, baner „Witryna może być zhakowana" w wynikach Google, skarga od dostawcy hostingu. Kolejność działań:

• Proszę natychmiast zmienić wszystkie hasła: panel administracyjny WordPressa, FTP/SFTP, baza danych, panel hostingu. Proszę zacząć od tego ostatniego. Jeśli haker jest w panelu hostingu, po prostu utworzy nowego administratora.

• Proszę przywrócić witrynę z kopii zapasowej wykonanej PRZED włamaniem. Świeża kopia zapasowa zrobiona po kompromitacji z dużym prawdopodobieństwem zawiera backdoor. Jeśli nie ma kopii zapasowej, następny krok.

• Proszę zainstalować Wordfence i uruchomić pełne skanowanie. Wtyczka znajdzie zmienione pliki rdzenia, podejrzany kod, ukryte backdoory. Proszę usunąć wszystko, co oznaczył skaner, a następnie zastąpić rdzeń WordPressa świeżą kopią: przycisk „Re-install" w Dashboard → Updates.

• *Proszę sprawdzić wp-content/uploads/ pod kątem obecności plików .php.* Nie powinno ich tam być. Każdy .php w folderze przesyłania to niemal na pewno shell.

Proszę obejrzeć powyższe wideo, omówiono w nim typowe błędy bezpieczeństwa WordPressa i sposoby ich naprawy, od słabych haseł po nieprawidłowe uprawnienia dostępu.

• Proszę podłączyć zewnętrzny monitoring. Sucuri, usługa chmurowa z WAF i zespołem reagowania. WAF filtruje ruch do serwera. W przypadku włamania zespół Sucuri czyści witrynę w ciągu kilku godzin. Cena od 199 USD rocznie za plan podstawowy z czyszczeniem i monitoringiem. To nie jest darmowe, ale gdy witryna zarabia, przestój kosztuje więcej.

Koniecznie proszę zarejestrować witrynę w Google Search Console. Jeśli Google zauważy złośliwy kod, otrzymają Państwo powiadomienie, zanim witryna wypadnie z wyników wyszukiwania.

Ochrona przed szantażystami: dlaczego backup rozwiązuje wszystko

Ransomware szyfruje pliki witryny i żąda okupu. Witryny WordPress to częsty cel: zamówienia, baza klientów, treści. Utrata wszystkiego w jedną noc to realny scenariusz bez backupu.

Trzy zasady:

• Backup poza serwerem. Chmura lub osobny FTP. UpdraftPlus i Duplicator automatyzują wysyłkę.
• Firewall i skaner. Wordfence + BBQ odcinają wgranie złośliwego pliku na etapie żądania.
• Źródła tylko oficjalne. Katalog WordPress.org i strony deweloperów z reputacją. Żadnych „darmowych" motywów z torrentów.

Automatyczne monitorowanie integralności plików

To ochrona serwerowa, nie jednorazowa akcja. Proszę zebrać kontrole w skrypt shellowy w cronie, raz na dobę, wynik na e-mail:

1
SITE_ROOT="/absolute/path/to/public_html"
2
 
3
find "$SITE_ROOT" -mtime -1 -name "*.php" \
4
    -printf '%TY-%Tm-%Td %TT\t%p\n' >> /tmp/file-changes.log
5
 
6
find "$SITE_ROOT" -mtime -7 -name "*.php" \
7
    | xargs grep -l -i "eval\|base64_decode\|iframe\|file_get_contents" \
8
    >> /tmp/suspicious-code.log
9
 
10
find "$SITE_ROOT/wp-content/uploads" -name "*.php" -print \
11
    >> /tmp/php-in-uploads.log
12
 
13
find /home -type d -perm 0777 >> /tmp/perms.log
14
find /home -type f -perm 0777 >> /tmp/perms.log
15
 
16
mailx -s "Webserver File Audit $(date +%F)" admin@example.com \
17
    < /tmp/suspicious-code.log

Skrypt uruchamia się raz na dobę przez cron. Pierwszy blok find -mtime -1 pokazuje pliki PHP zmodyfikowane w ciągu ostatnich 24 godzin, to główny detektor włamań. Drugi szuka sygnatur shelli: eval, base64_decode, ukrytych iframe. Trzeci wyłapuje PHP w folderze uploads, legalne PHP tam nie występuje. Czwarty znajduje pliki i foldery z uprawnieniami 777. Wynik trafia na e-mail. Profilaktyka wyłapuje włamanie na wczesnym etapie, zanim Google zauważy i zbanuje witrynę w wynikach wyszukiwania.

Sucuri: firewall chmurowy, gdy nie ma Pan/Pani czasu na grzebanie

Zasada działania: ruch przechodzi przez chmurowy proxy Sucuri z WAF, złośliwe żądania są odcinane przed dotarciem do hostingu. Witryna ładuje się szybciej dzięki CDN. Kluczowe możliwości: WAF z sygnaturami w czasie rzeczywistym, ochrona przed DDoS, automatyczne czyszczenie z malware.

Plany od 199 USD rocznie. Darmowej wersji nie ma, ale wtyczka skaner Sucuri sprawdza pliki pod kątem zmian bez WAF. Dla witryny komercyjnej to uzasadniona inwestycja. Dla osobistego bloga wystarczy Wordfence + BBQ.

⁉️🤔 Często zadawane pytania

Czy WordPress sam w sobie jest bezpieczny?

Rdzeń WordPressa sprawdzają setki programistów i audytorów bezpieczeństwa. Problem nie leży w rdzeniu, problem tkwi w nieaktualnych wtyczkach, motywach z niesprawdzonych źródeł i hasłach typu 123456. Regularne aktualizacje plus podstawowy firewall dają wystarczającą ochronę dla większości stron.

Czy można obejść się bez wtyczek bezpieczeństwa?

Można, jeśli jest Pan/Pani gotów ręcznie skonfigurować firewall na poziomie serwera: iptables, mod_security, 7G/8G Firewall w .htaccess, śledzić CVE dla każdej wtyczki i pisać skrypty cron do monitorowania. Dla wszystkich pozostałych instalacja Wordfence lub Solid Security to godzina w porównaniu z dziesiątkami godzin pracy ręcznej.

Czy aktualizacje są potrzebne, jeśli stoi firewall?

Tak, obowiązkowo. Firewall odcina ataki „z zewnątrz", ale jeśli zainstalowana jest wtyczka ze znaną luką, prędzej czy później znajdzie się wektor, którego firewall nie przechwyci. Aktualizacje wszystkich komponentów WordPressa to podstawa, bez której inne środki działają na pół gwizdka.

Jaką wtyczkę bezpieczeństwa wybrać?

Do minimalnej ochrony: BBQ Firewall, blokuje szkodliwe zapytania URL, zero konfiguracji. Do pełnej ochrony: Wordfence, WAF, skaner, 2FA, ochrona przed brute force, wszystko w darmowej wersji. Zestaw BBQ + Wordfence pokrywa oba poziomy bez konfliktów.

Co zrobić z REST API, wyłączać?

REST API jest potrzebne WordPressowi do działania edytora bloków Gutenberg, szeregu wtyczek i integracji zewnętrznych. Całkowite wyłączenie zepsuje panel administracyjny. Zamiast tego proszę ograniczyć dostęp: dla nieuwierzytelnionych użytkowników pozostawić tylko publiczne endpointy. Wtyczka REST API Toolbox pozwala elastycznie skonfigurować dostęp bez interwencji chirurgicznej.

Jak często sprawdzać stronę pod kątem wirusów?

Automatycznie, codziennie przez skrypty cron: sprawdzanie zmienionych plików, wyszukiwanie .php w uploads. Ręcznie, raz w miesiącu: wejść do Wordfence, uruchomić pełne skanowanie, sprawdzić listę wtyczek pod kątem porzuconych. Brak aktualizacji od ponad roku, usunąć lub zastąpić.

Czy można stracić pozycje w Google przez włamanie?

Można, i to szybko. Google skanuje strony w poszukiwaniu szkodliwego kodu i oznacza zainfekowane ostrzeżeniem w wynikach wyszukiwania. Jeśli włamanie nie zostanie usunięte w ciągu kilku tygodni, strona zostanie usunięta z indeksu. Proszę zarejestrować stronę w Google Search Console, otrzyma Pan/Pani powiadomienie o problemie natychmiast po wykryciu.

Czy zmiana hostingu pomoże w ochronie przed włamaniami?

Częściowo. Dobry hosting dodaje własne warstwy: izolacja kont, monitoring sieci, automatyczne aktualizacje PHP. Ale hosting nie chroni przed dziurawą wtyczką, którą sam Pan/Pani zainstalował, ani przed hasłem qwerty. Bezpieczeństwo to tort warstwowy: hosting plus aktualizacje plus firewall plus uprawnienia dostępu plus kopie zapasowe.

Bezpieczeństwo WordPressa: od czego zacząć jeszcze dziś

Główna zasada bezpieczeństwa WordPressa to nie próbować ogarnąć nieogarnionego za jednym razem. Proszę zacząć od trzech kroków:

• Jeśli nie ma firewalla, proszę zainstalować BBQ Firewall. Jedna minuta.
• Jeśli nie ma kopii zapasowych poza serwerem, proszę skonfigurować UpdraftPlus z wysyłaniem do chmury. Dziesięć minut.
• Jeśli nie jest włączone 2FA dla administratorów, proszę włączyć przez Wordfence. Pięć minut.

Następnie proszę wracać do powyższej listy: wyłączyć xmlrpc, zaktualizować sole, wyłączyć edytor plików, skonfigurować security headers. Jeden punkt dziennie, a po tygodniu strona będzie chroniona o rząd wielkości lepiej niż wczoraj.

A jakie środki bezpieczeństwa działają już na Pana/Pani stronie? Proszę napisać w komentarzach, ciekawie jest porównać podejścia.