# Jak zabezpieczyć WordPress 2026 — poradnik techniczny i checklist

> Zabezpieczenie WordPress wymaga pracy na kilku warstwach: aktualizacji, kont, serwera, monitoringu i kopii zapasowych. Poradnik wyjaśnia, co sprawdzić przed zmianą uprawnień, konfiguracji wp-config czy WAF oraz jak przygotować procedurę reagowania na incydent.

Autor: WebAlpha (WebAlpha). Opublikowano: 2026-06-08. Zaktualizowano: 2026-09-07. Kanoniczny adres: https://webalpha.pl/blog/bezpieczenstwo-wordpress-2026

Około 17 min czytania (szacunek; bez czasu wykonania instrukcji).

WordPress jest popularnym celem automatycznych ataków ze względu na skalę instalacji oraz duży ekosystem wtyczek i motywów. Sam udział incydentów w próbkach firm bezpieczeństwa nie dowodzi jednak, że rdzeń platformy jest z definicji słaby — wynik zależy też od sposobu doboru badanych witryn. Praktyczny wniosek jest prosty: aktualizacje, ograniczenie dodatków i monitoring są ważniejsze niż efektowny procent bez metodologii.

Podatne komponenty, przejęte hasła i zbyt szeroki dostęp do plików to odrębne ścieżki ryzyka. Sprawdzenie samej wersji WordPressa nie obejmuje wszystkich tych obszarów. Poniższy checklist jest punktem wyjścia do oceny konkretnej instalacji, nie certyfikatem bezpieczeństwa.

> **Bezpieczeństwo to proces, nie jednorazowe działanie:** Nawet jeśli dziś zaimplementujesz wszystkie punkty z tego checklistu, bezpieczeństwo strony wymaga regularnej uwagi: aktualizacji, monitorowania logów i weryfikacji backupów. Jednorazowe 'zabezpieczenie' bez dalszej opieki daje fałszywe poczucie bezpieczeństwa.

<a id="sekcja-warstwa-1-aktualizacje-i-ocena-podatnosci"></a>

## Warstwa 1 — Aktualizacje i ocena podatności

Dla każdego komponentu sprawdź zainstalowaną wersję, komunikaty autora i znane podatności. O pilności decydują m.in. możliwość wykorzystania bez logowania, dostępny exploit, uprawnienia potrzebne do ataku i ekspozycja funkcji na Twojej stronie. Nie czekaj na miesięczny przegląd, gdy komunikat wymaga pilnej aktualizacji lub czasowego wyłączenia podatnej funkcji.

<a id="sekcja-krok-1-wdroz-systematyczny-proces-aktualizacji"></a>

### Krok 1: Wdroż systematyczny proces aktualizacji

WordPress core: sprawdź ustawienia automatycznych aktualizacji i politykę hostingu. Stała define('WP_AUTO_UPDATE_CORE', 'minor'); dopuszcza automatyczne wydania utrzymaniowe i bezpieczeństwa w danej gałęzi. Nie gwarantuje ich wykonania: wpływ mają też uprawnienia, harmonogram zadań, filtry i inne ustawienia. Weryfikuj wynik aktualizacji oraz możliwość odtworzenia.

Wtyczki: po komunikacie o aktualizacji przeczytaj changelog i ustal priorytet. Krytyczne ścieżki, takie jak płatności i formularze, testuj na stagingu oraz po wdrożeniu. Pilną lukę obsłuż według oceny ryzyka, nie wyłącznie stałego terminu przeglądu.

Motywy: sprawdź aktywny motyw, jego rodzica i własne modyfikacje. Usuń zbędne dodatki po sprawdzeniu zależności; nieaktywny komponent może nadal zawierać pliki dostępne bezpośrednio przez serwer.

- Zweryfikuj politykę automatycznych aktualizacji core i raport ich wykonania
- Pulpit → Aktualizacje oraz bieżące komunikaty bezpieczeństwa autorów
- Usuń nieużywane wtyczki i motywy (nawet zdezaktywowane)
- Oceń wersję, wsparcie autora, zgodność i znane podatności każdej wtyczki

> **Brak aktualizacji nie oznacza automatycznie statusu „closed”:** Data ostatniego wydania jest sygnałem do weryfikacji, a nie dowodem porzucenia. WordPress.org może zamknąć wtyczkę m.in. z powodu naruszenia zasad, problemu bezpieczeństwa lub na prośbę autora. Sam upływ 12 miesięcy od aktualizacji nie uruchamia takiej reguły. Sprawdź komunikat katalogu, status wsparcia i podatności dotyczące używanej wersji.

Podstawa weryfikacji: [aktualizacje WordPress](https://developer.wordpress.org/advanced-administration/upgrade/upgrading/) oraz [zasady zamykania wtyczek w katalogu](https://developer.wordpress.org/plugins/wordpress-org/plugin-developer-faq/).

<a id="sekcja-warstwa-2-hasla-i-polityka-dostepu"></a>

## Warstwa 2 — Hasła i polityka dostępu

<a id="sekcja-krok-2-wdroz-silna-polityke-hasel"></a>

### Krok 2: Wdroż silną politykę haseł

Nazwa użytkownika nie powinna być traktowana jak sekret: bywa widoczna w treści lub metadanych strony. Zmiana nazwy 'admin' nie zastępuje silnego hasła, 2FA i ograniczenia prób logowania. Przed usunięciem starego konta sprawdź nowe logowanie i przypisanie opublikowanych treści.

Używaj długiego, unikalnego hasła wygenerowanego przez menedżer haseł lub odpowiednio długiej frazy. Nie stosuj tego samego hasła do WordPressa, poczty i hostingu. Zabezpiecz również konto menedżera haseł oraz procedurę odzyskiwania dostępu.

Użytkownicy: ogranicz liczbę kont z rolą Administrator do absolutnego minimum. Każda osoba, która potrzebuje dostępu do panelu, powinna mieć konto z minimalną rolą odpowiadającą jej zadaniom.

- Zmień nazwę użytkownika 'admin' (lub usuń i stwórz nowe konto z inną nazwą)
- Sprawdź: Użytkownicy → wszystkich użytkowników z rolą Administrator
- Usuń konta użytkowników, które nie są aktywnie używane
- Zweryfikuj adresy e-mail kont — nieaktualne e-maile utrudniają odzyskanie konta

<a id="sekcja-warstwa-3-dwuskladnikowe-uwierzytelnienie-2fa"></a>

## Warstwa 3 — Dwuskładnikowe uwierzytelnienie (2FA)

<a id="sekcja-krok-3-wlacz-2fa-dla-wszystkich-kont-administracyjnych"></a>

### Krok 3: Włącz 2FA dla wszystkich kont administracyjnych

2FA dodaje drugi składnik do logowania i ogranicza ryzyko użycia samego skradzionego hasła. Nie chroni jednak przed każdą ścieżką przejęcia konta: trzeba uwzględnić phishing, kradzież sesji i mechanizmy odzyskiwania dostępu.

Przed wyborem rozwiązania sprawdź zgodność z używanym formularzem logowania, SSO i kontami klientów. Porównaj obsługiwane metody uwierzytelnienia, możliwość egzekwowania 2FA dla ról oraz procedurę awaryjną. Nie zakładaj, że wszystkie funkcje są dostępne w każdym planie wtyczki.

Wdrożenie: skonfiguruj i przetestuj 2FA na własnym koncie, a następnie wdrażaj je dla kolejnych osób. Zapisz kody odzyskiwania poza stroną i ustal, kto może odblokować konto. Słabiej chroniony e-mail awaryjny może podważyć ochronę drugiego składnika.

- Wybierz rozwiązanie 2FA zgodne z używanymi ścieżkami logowania
- Skonfiguruj dla konta głównego administratora
- Wymuś 2FA dla wszystkich ról Admin i Editor
- Zapisz kody zapasowe w bezpiecznym miejscu
- Przetestuj logowanie z nowym urządzeniem

<a id="sekcja-warstwa-4-uprawnienia-plikow-i-folderow"></a>

## Warstwa 4 — Uprawnienia plików i folderów

Uprawnienia decydują, które konta systemowe mogą czytać i modyfikować pliki. Zbyt szeroki zapis może zwiększyć skutki włamania; zbyt restrykcyjna zmiana może zatrzymać stronę lub aktualizacje. Ustawienia trzeba dobrać do użytkownika procesu PHP, grup, ACL i sposobu wdrażania na konkretnym hostingu.

<a id="sekcja-krok-4-sprawdz-i-ustaw-wlasciwe-uprawnienia-plikow"></a>

### Krok 4: Sprawdź i ustaw właściwe uprawnienia plików

Zacznij od odczytu aktualnego właściciela, grupy i uprawnień oraz dokumentacji hostingu. Wartości 755 dla katalogów i 644 dla plików są spotykanym punktem odniesienia, nie uniwersalnym poleceniem dla całej instalacji. Zachowaj wymagane wyjątki i sprawdź ewentualne ACL.

Nie uruchamiaj rekurencyjnego chmod ani chown na przypadkowej ścieżce. Najpierw ustal katalog instalacji, model wdrażania i zakres zmiany. Przetestuj ją na stagingu oraz zapisz poprzednie ustawienia, by móc je przywrócić.

Nie ma zasady, że wszystkie pliki muszą należeć do użytkownika PHP-FPM. Konto wdrożeniowe może być właścicielem kodu, a PHP otrzymać zapis tylko do potrzebnych katalogów. wp-config.php powinien być czytelny dla uprawnionych procesów, ale niedostępny dla innych kont; 400 i 440 mają różne znaczenie dla grupy i mogą nie pasować do hostingu.

- Ustal użytkownika PHP, właściciela kodu, grupy i ACL
- Ogranicz zapis do miejsc wymaganych przez funkcje i proces aktualizacji
- Sprawdź, które konta mogą odczytać wp-config.php i kopie tego pliku
- Przetestuj przesyłanie mediów, cache, aktualizacje oraz działanie strony
- Zachowaj zapis ustawień przed zmianą i procedurę wycofania

<a id="sekcja-warstwa-5-zabezpieczenie-wp-config-php"></a>

## Warstwa 5 — Zabezpieczenie wp-config.php

Plik wp-config.php może zawierać dane dostępowe do bazy, klucze i inne sekrety. Ich ujawnienie jest poważnym incydentem; zakres skutków zależy m.in. od uprawnień konta bazy i dostępności usług. Chroń też kopie, archiwa oraz pliki tymczasowe konfiguracji.

<a id="sekcja-krok-5-zabezpiecz-wp-config-php"></a>

### Krok 5: Zabezpiecz wp-config.php

WordPress obsługuje wp-config.php jeden poziom nad katalogiem instalacji, ale nie przenoś go automatycznie. Sprawdź rzeczywisty katalog publiczny, sąsiednie aplikacje, uprawnienia i zgodność hostingu. Katalog nadrzędny nie musi być poza zasięgiem HTTP, a błędna relokacja może pogorszyć ochronę.

Na Apache 2.4 reguła ochrony pliku używa Require all denied wewnątrz bloku <Files "wp-config.php">. Zastosuj ją tylko po sprawdzeniu konfiguracji serwera i obsługi .htaccess. Nginx wymaga własnej reguły w konfiguracji serwera. Po zmianie przetestuj odpowiedź HTTP i logowanie do WordPressa; nie wklejaj historycznych dyrektyw Apache 2.2 Order/Deny.

Po podejrzeniu ujawnienia kluczy lub przy rotacji wygeneruj nowe salts przez oficjalny endpoint https://api.wordpress.org/secret-key/1.1/salt/ i podmień istniejące definicje. Zmiana unieważnia standardowe cookies logowania WordPressa, ale nie zastępuje przeglądu kont, tokenów, application passwords i przyczyny incydentu.

Na produkcji nie pokazuj błędów odwiedzającym. Sprawdź WP_DEBUG i WP_DEBUG_DISPLAY oraz ustawienia PHP hostingu; logi diagnostyczne przechowuj w chronionej lokalizacji z kontrolowaną retencją. Samo ustawienie WP_DEBUG na false nie zastępuje konfiguracji logowania i display_errors serwera.

- Sprawdź, czy konfiguracja i jej kopie nie są dostępne przez HTTP
- Dobierz regułę ochrony do Apache, Nginx lub konfiguracji hostingu
- Zapewnij odpowiednio ograniczony odczyt konfiguracji przez konta systemowe
- Po incydencie zaplanuj rotację sekretów oraz unieważnienie dostępów
- Wyłącz wyświetlanie błędów użytkownikom; zabezpiecz logi diagnostyczne

Dokumentacja do tych zmian: [uprawnienia plików WordPress](https://developer.wordpress.org/advanced-administration/server/file-permissions/), [hardening i ochrona wp-config.php](https://developer.wordpress.org/advanced-administration/security/hardening/) oraz [ustawienia wp-config.php](https://developer.wordpress.org/advanced-administration/wordpress/wp-config/).

<a id="sekcja-warstwa-6-ochrona-przed-atakami-brute-force-na-wp-admin"></a>

## Warstwa 6 — Ochrona przed atakami brute force na wp-admin

<a id="sekcja-krok-6-ogranicz-dostep-do-wp-login-php-i-wp-admin"></a>

### Krok 6: Ogranicz dostęp do wp-login.php i wp-admin

Ataki brute force na WordPress polegają na automatycznym próbowaniu tysięcy kombinacji loginów i haseł. Ograniczenie liczby prób logowania jest podstawowym środkiem zaradczym.

Opcja 1 — ograniczenie dostępu: przy stałym adresie IP lub VPN można ograniczyć dostęp do administracji na poziomie serwera lub proxy. Zaplanuj dostęp awaryjny i sprawdź admin-ajax.php oraz integracje; blokada całego wp-admin może zepsuć funkcje dostępne odwiedzającym.

Opcja 2 — limity prób: skonfiguruj ograniczenia logowania w wybranej warstwie bezpieczeństwa. Ustal progi, czas blokady i wyjątki, a następnie sprawdź adres klienta za proxy/CDN. Błędne rozpoznawanie IP może blokować wielu użytkowników jednocześnie.

Opcja 3 — zmiana URL logowania może ograniczyć część ruchu kierowanego na domyślną ścieżkę. Nie zastępuje 2FA, limitów ani silnych haseł. Przetestuj zgodność z resetem hasła, cache, SSO i formularzem logowania sklepu.

- Zainstaluj wtyczkę limitowania prób logowania
- Dobierz próg i czas blokady do logów oraz ryzyka blokowania prawidłowych użytkowników
- Włącz powiadomienia e-mail o zablokowanych próbach
- Przetestuj logowanie, reset hasła i dostęp awaryjny
- Przy ograniczeniu IP sprawdź wyjątki dla funkcji publicznych i integracji

<a id="sekcja-warstwa-7-naglowki-http-i-konfiguracja-serwera"></a>

## Warstwa 7 — Nagłówki HTTP i konfiguracja serwera

<a id="sekcja-krok-7-dodaj-naglowki-bezpieczenstwa-http"></a>

### Krok 7: Dodaj nagłówki bezpieczeństwa HTTP

Nagłówki HTTP mogą ograniczać wybrane zachowania przeglądarki. Ich skuteczność zależy od polityki, obsługi w przeglądarce i kontekstu aplikacji. Nie naprawiają podatnego kodu; błędna konfiguracja może zablokować osadzane formularze, płatności albo skrypty.

Dobierz nagłówki w konfiguracji serwera lub proxy, unikając sprzecznych wartości z kilku warstw. Po wdrożeniu przetestuj kluczowe ścieżki i odpowiedzi HTTP, także przy błędach i przekierowaniach.

- X-Frame-Options: SAMEORIGIN — zapobiega osadzeniu strony w iframe na obcych domenach (ochrona przed clickjacking)
- X-Content-Type-Options: nosniff — zapobiega MIME-type sniffing przez przeglądarkę
- Referrer-Policy: strict-origin-when-cross-origin — kontroluje przekazywanie adresu strony
- Strict-Transport-Security: wdrażaj po sprawdzeniu HTTPS i odnawiania certyfikatów, zaczynając od kontrolowanego max-age. includeSubDomains obejmuje też subdomeny, więc wymaga ich pełnej inwentaryzacji i gotowości HTTPS. Preload to osobna, długoterminowa decyzja, nie domyślny dodatek.
- Permissions-Policy: ogranicz nieużywane funkcje przeglądarki, np. kamerę lub geolokalizację, po sprawdzeniu potrzeb formularzy i aplikacji.
- Content-Security-Policy: opracuj politykę dla rzeczywistych źródeł zasobów; tryb Report-Only może pomóc zebrać naruszenia przed egzekwowaniem. Nie dodawaj przestarzałego X-XSS-Protection jako zamiennika CSP.

Szczegóły wdrożenia: [HSTS i zakres subdomen w MDN](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Strict-Transport-Security) oraz [Content Security Policy](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Content-Security-Policy).

<a id="sekcja-warstwa-8-wtyczki-bezpieczenstwa-kiedy-pomagaja-kiedy-przeszkadzaja"></a>

## Warstwa 8 — Wtyczki bezpieczeństwa: kiedy pomagają, kiedy przeszkadzają

Porównuj konkretne funkcje i sposób wdrożenia, nie samą nazwę „security”. Skaner, historia zmian, 2FA oraz WAF rozwiązują różne problemy. Sprawdź też aktualność reguł, obsługę incydentów, koszty licencji i obciążenie na swoim hostingu.

<a id="sekcja-co-robia-dobrze"></a>

### Co robią dobrze

- Wordfence Free zawiera WAF działający na serwerze, skaner oraz funkcje ochrony logowania. W trybie Extended Protection WAF uruchamia się przed kodem WordPressa; optymalizacja wymaga zgodności konfiguracji PHP i testów.
- Bezpłatna wtyczka Sucuri Security służy m.in. do audytu i monitorowania integralności. Sucuri Website Firewall działający poza serwerem jest oddzielną płatną usługą — sama instalacja darmowej wtyczki go nie włącza.
- WAF w usłudze zewnętrznej filtruje ruch przechodzący przez tę usługę przed serwerem źródłowym. Trzeba poprawnie skonfigurować DNS, certyfikaty, adresy klienta i ochronę przed ominięciem proxy.
- Zakres skanowania, aktualność reguł i wsparcie incydentalne porównaj w aktualnej dokumentacji konkretnego planu. Płatna licencja nie stanowi gwarancji braku włamania.

<a id="sekcja-ograniczenia-wtyczek-bezpieczenstwa"></a>

### Ograniczenia wtyczek bezpieczeństwa

- WAF i skanowanie nie zastępują usunięcia podatności ani kontroli dostępów. Negatywny wynik skanu nie dowodzi, że cała instalacja jest czysta.
- WAF na serwerze oraz WAF przed serwerem mają inne punkty kontroli. Nie ma uniwersalnej przewagi bez oceny reguł, konfiguracji, dostępności i możliwości obejścia danej warstwy.
- Nakładające się moduły blokowania, 2FA lub edycji reguł mogą kolidować. Wyznacz odpowiedzialność każdej warstwy i testuj ich współpracę; liczba wtyczek nie jest miarą ochrony.
- Skanowanie zużywa zasoby serwera. Dobierz harmonogram i limity do pomiarów CPU, I/O i ruchu, zamiast zakładać, że konkretny produkt będzie lekki albo ciężki dla każdej strony.
- Fałszywe poczucie bezpieczeństwa: posiadanie wtyczki bezpieczeństwa nie oznacza, że strona jest zabezpieczona. Wtyczka jest tylko jedną warstwą.

Funkcje i architektura: [Wordfence Free](https://www.wordfence.com/help/wordfence-free/), [tryby ochrony Wordfence WAF](https://www.wordfence.com/help/firewall/optimizing-the-firewall/) i [Sucuri — wtyczka a płatna usługa firewall](https://sucuri.net/faq/). Stan weryfikacji: 3 września 2026 r.

<a id="sekcja-warstwa-9-backup-plan-na-najgorszy-scenariusz"></a>

## Warstwa 9 — Backup: plan na najgorszy scenariusz

<a id="sekcja-krok-8-wdroz-automatyczne-backupy-z-weryfikacja"></a>

### Krok 8: Wdroż automatyczne backupy z weryfikacją

Backup jest mechanizmem odtworzenia po awarii lub incydencie, nie gwarancją zachowania wszystkich danych. Jego wartość zależy od kompletności, wieku i możliwości przywrócenia. Oprócz wykonania kopii sprawdź jej odseparowanie i rzeczywisty wynik odtworzenia.

Rozwiązanie kopii dobierz do rozmiaru strony, częstotliwości zmian i możliwości odtworzenia. Sprawdź, czy obejmuje bazę, pliki, konfigurację i wymagane klucze, jak zapewnia spójność kopii oraz kto ma dostęp do zasobu docelowego. Dotyczy to zarówno wtyczki, jak i backupu wykonywanego przez hosting lub administratora.

Co najmniej jedną kopię odseparuj od serwera i jego danych dostępowych. Kopia na tym samym koncie może pomóc przy błędzie aplikacji, ale nie powinna być jedyną ochroną przed przejęciem konta lub utratą infrastruktury. Rozważ wersjonowanie i ochronę przed skasowaniem, jeśli odpowiadają ryzyku.

- Ustal RPO — ile danych wolno stracić — i na tej podstawie częstotliwość kopii
- Ustal RTO — wymagany czas przywrócenia — i sprawdź go w teście
- Dobierz retencję do ryzyka późnego wykrycia problemu, kosztów i zasad przechowywania danych
- Odseparuj kopię od konta produkcyjnego i ogranicz dostęp do niej
- Testuj przywrócenie według harmonogramu oraz po istotnej zmianie mechanizmu kopii

Praktyczne wykonanie kopii bazy i plików, kontrolę sum oraz odzyskanie danych na osobnym środowisku opisuje [instrukcja backupu i przywracania WordPressa](https://webalpha.pl/blog/kopia-zapasowa-wordpress-przywracanie). Po incydencie nie zakładaj automatycznie, że ostatnia kopia jest czysta: ustal zakres kompromitacji i wybierz właściwy punkt odtworzenia.

Plik robots.txt nie chroni kopii, panelu ani logów przed odczytem. Pokazujemy tę różnicę w [testach robots.txt, noindex i dostępu HTTP w WordPressie](https://webalpha.pl/blog/robots-txt-wordpress). Dane poufne wymagają kontroli dostępu po stronie serwera; wpis Disallow jest wyłącznie instrukcją dla współpracującego robota.

<a id="sekcja-warstwa-10-wylacz-edycje-plikow-z-poziomu-panelu"></a>

## Warstwa 10 — Wyłącz edycję plików z poziomu panelu

Domyślnie WordPress pozwala edytować pliki motywów i wtyczek bezpośrednio z panelu administracyjnego (Wygląd → Edytor, Wtyczki → Edytor wtyczek). Jeśli atakujący przejmie konto administratora — może wstrzyknąć złośliwy kod przez ten interfejs bez dostępu do FTP.

- Wyłącz edytor plików w wp-config.php: define('DISALLOW_FILE_EDIT', true);
- DISALLOW_FILE_MODS ogranicza modyfikacje plików, w tym mechanizmy instalacji i aktualizacji. Używaj tej polityki tylko z przetestowanym procesem wdrożeniowym; sprawdź też automatyczne aktualizacje i zachowanie narzędzi administracyjnych. Samo wpisanie „aktualizacje przez CLI” nie rozwiązuje konfliktu konfiguracji.
- Oceń, czy XML-RPC jest potrzebny aplikacjom i integracjom. Jeśli nie, ogranicz ten punkt wejścia regułą właściwą dla serwera; w Apache 2.4 używa się Require all denied w odpowiednim bloku Files. Po zmianie sprawdź integracje i logi. Nie stosuj historycznych reguł Order/Deny.

<a id="sekcja-warstwa-11-https-i-certyfikat-ssl"></a>

## Warstwa 11 — HTTPS i certyfikat SSL

HTTPS chroni transmisję pomiędzy przeglądarką a serwerem. Poprawna konfiguracja obejmuje certyfikat, odnawianie, przekierowania i zasoby strony; nie potwierdza jednak bezpieczeństwa kodu ani wiarygodności firmy. Nie traktuj wdrożenia HTTPS jako obietnicy wzrostu pozycji w Google.

- Zainstaluj certyfikat SSL (Let's Encrypt lub komercyjny) i skonfiguruj HTTPS.
- Wymuś przekierowanie HTTP → HTTPS w .htaccess lub w konfiguracji serwera.
- Sprawdź, czy WordPress ma poprawnie ustawiony URL strony (wp-config lub Ustawienia → Ogólne): https://twojadomena.pl
- Sprawdź mixed content: część zasobów HTTP może być blokowana lub automatycznie podnoszona do HTTPS. Przed zmianą URL-i w bazie wykonaj kopię i test na stagingu; użyj narzędzia obsługującego dane serializowane.
- HSTS wdrażaj etapowo według zasad z sekcji nagłówków, bez automatycznego includeSubDomains lub preload.

<a id="sekcja-warstwa-12-procedura-reagowania-na-incydent-malware"></a>

## Warstwa 12 — Procedura reagowania na incydent (malware)

Jeśli strona została zainfekowana, kluczowe jest działanie zgodnie z planem — panika i losowe próby naprawy mogą uszkodzić dowody lub utrudnić całkowite czyszczenie.

1. Zabezpiecz kopię stanu strony i dostępne logi w odizolowanym miejscu. Traktuj ją jako materiał potencjalnie złośliwy i zawierający dane osobowe; nie publikuj archiwum ani nie uruchamiaj go na produkcji.
2. Przełącz stronę w tryb maintenance lub skieruj ruch na statyczną stronę zastępczą — żeby nie narażać kolejnych użytkowników.
3. Z czystego urządzenia zabezpiecz konta hostingu, WordPressa i powiązanych usług oraz unieważnij zbędne sesje i tokeny. Zaplanuj rotację haseł, kluczy API i salts; po usunięciu przyczyny sprawdź, czy nowe sekrety nie były dostępne zainfekowanemu systemowi.
4. Użyj skanera plików i analizy logów. Sucuri SiteCheck ocenia publicznie dostępną odpowiedź witryny, nie wszystkie pliki na serwerze. Wzorce takie jak eval lub base64_decode wymagają analizy kontekstu — samo znalezienie ciągu nie dowodzi infekcji, a jego brak nie wyklucza malware.
5. Zweryfikuj integralność core, np. wp core verify-checksums dla właściwej wersji i lokalizacji. Niezgodność wymaga wyjaśnienia: może wynikać z modyfikacji, uszkodzenia lub infekcji. Ten test nie obejmuje całej bazy, uploads ani każdego niestandardowego komponentu.
6. Sprawdź bazę danych: wp_options (siteurl, home, często modyfikowane), wp_users (nieautoryzowane konta admin), wp_posts (wstrzykiwane linki lub JavaScript).
7. Znajdź wektor ataku — bez ustalenia, jak doszło do infekcji, czyszczenie może okazać się tymczasowe. Sprawdź logi dostępu serwera, daty modyfikacji plików, listę zainstalowanych wtyczek i ich wersje.
8. Odtwórz zaufany kod i usuń przyczynę: zaktualizuj podatne komponenty albo zastąp je zgodnymi rozwiązaniami. Przetestuj zależności, zamiast usuwać każdą wtyczkę wyłącznie na podstawie wieku wydania.
9. Przywróć zweryfikowaną czystą kopię lub odbuduj instalację z zaufanych źródeł. Sam powrót do backupu nie zamyka luki. Przed przywróceniem ruchu sprawdź bazę, konta, zadania cykliczne, integracje i kluczowe funkcje; kontynuuj monitoring.
10. Jeżeli raport Problemy dotyczące bezpieczeństwa w Search Console zawiera zgłoszenie, po usunięciu wszystkich wskazanych problemów w całej witrynie i testach wybierz Poproś o sprawdzenie. Opisz przyczynę i naprawę. To wniosek o weryfikację bezpieczeństwa, nie żądanie indeksowania URL-a.

Procedurę zgłoszenia opisuje [raport problemów bezpieczeństwa Google](https://support.google.com/webmasters/answer/9044101?hl=pl). Jeśli incydent mógł objąć dane osobowe lub płatności, przekaż ustalenia osobie odpowiedzialnej za ochronę danych i operatorowi płatności; obowiązki zgłoszeniowe wymagają odrębnej oceny zdarzenia.

Dla sklepów przeczytaj również [wyjaśnienie odpowiedzialności PCI DSS w dokumentacji WooCommerce](https://woocommerce.com/document/pci-dss-compliance-and-woocommerce/). Zakres zależy od integracji płatniczej; użycie zewnętrznej bramki nie jest samodzielnym potwierdzeniem zgodności całego sklepu.

Reagowanie na incydenty bezpieczeństwa WordPress wymaga doświadczenia. Jeśli strona jest zainfekowana lub chcesz zlecić regularną opiekę techniczną — sprawdź naszą usługę [opieki technicznej nad stronami](https://webalpha.pl/opieka-techniczna/strony) i [administracji i aktualizacji](https://webalpha.pl/opieka-techniczna/administracja-aktualizacje). Więcej o tym, co obejmuje kompleksowa opieka nad WordPress, znajdziesz w artykule [opieka nad stroną WordPress](https://webalpha.pl/blog/opieka-nad-strona-wordpress).

<a id="sekcja-checklist-bezpieczenstwa-wordpress-szybka-lista-kontrolna"></a>

## Checklist bezpieczeństwa WordPress — szybka lista kontrolna

- WordPress core, wtyczki i motywy — aktualne.
- Nieużywane wtyczki i motywy — usunięte.
- Hasło administratora — silne, unikalne, w menedżerze haseł.
- Konta uprzywilejowane — imienne, uzasadnione i okresowo przeglądane.
- 2FA — włączone dla wszystkich kont z rolą Administrator.
- Uprawnienia plików — zgodne z użytkownikami, grupami i modelem wdrożenia hostingu.
- wp-config.php i jego kopie — chronione przed nieuprawnionym odczytem oraz dostępem HTTP.
- Security Keys w wp-config.php — wygenerowane i aktualne.
- WP_DEBUG — wyłączony na produkcji.
- DISALLOW_FILE_EDIT — włączone.
- XML-RPC — wyłączone jeśli nieużywane.
- Nagłówki bezpieczeństwa HTTP — X-Frame-Options, HSTS, X-Content-Type-Options.
- HTTPS — aktywne, wymuszony redirect HTTP → HTTPS.
- Backup — częstotliwość i retencja dobrane do RPO/RTO, kopia odseparowana od produkcji.
- Backup — przetestowany przez przywrócenie na staging.
- Limit prób logowania — aktywny.
- Warstwy bezpieczeństwa — uzgodniony zakres, sprawdzona konfiguracja i brak konfliktów.
- Monitoring — powiadomienia o nieautoryzowanym logowaniu.

## Potrzebujesz regularnej opieki technicznej nad WordPressem?

W WebAlpha ustalamy zakres opieki nad WordPressem: aktualizacje, monitoring, kopie zapasowe, testy i raportowanie. Opisz stronę oraz krytyczne funkcje — przed wyceną określimy odpowiedzialność, czas reakcji i zakres prac incydentalnych.

[Sprawdź zakres opieki nad WordPressem](https://webalpha.pl/opieka-techniczna/strony)

## Najczęstsze pytania (FAQ)

### Jak zabezpieczyć WordPress przed hakerami?

Kluczowe działania to: regularne aktualizacje rdzenia, wtyczek i motywów, ograniczenie dodatków, silne unikalne hasła z menedżerem haseł, 2FA dla kont administracyjnych, właściwe uprawnienia plików, kontrola edycji kodu z panelu oraz testowane kopie poza serwerem. Priorytety podatności ustalaj według wersji, ekspozycji i wiarygodnych komunikatów bezpieczeństwa.

### Która wtyczka bezpieczeństwa WordPress jest najlepsza?

Nie ma jednego wyboru dla każdej instalacji. Porównaj WAF, skanowanie, ochronę logowania, aktualność reguł, wymagania hostingu i zakres wsparcia. Wordfence Free obejmuje WAF oraz skaner; darmowa wtyczka Sucuri Security nie włącza płatnego Sucuri Website Firewall. Testuj konfigurację i współpracę używanych warstw.

### Czy potrzebuję płatnej wtyczki bezpieczeństwa WordPress?

Decyzja zależy od ryzyka, brakujących funkcji i zdolności zespołu do reagowania. Sprawdź, co realnie zmienia płatny plan: reguły, wsparcie, skanowanie lub usługę przed serwerem. Płatny Wordfence nie zmienia automatycznie lokalnego WAF w zewnętrzne proxy, a darmowa wtyczka Sucuri nie obejmuje płatnego firewalla. Licencja nie zastępuje aktualizacji, kopii i procedur.

### Jak sprawdzić czy moja strona WordPress jest zainfekowana?

Oznaki infekcji: nieznane pliki lub kody w katalogach WordPress, nieautoryzowane konta administratora, przekierowania na obce strony, Google ostrzega użytkowników, hosting zawiesił konto za spam. Narzędzia do sprawdzenia: Sucuri SiteCheck (sucuri.net/website-scanner), Wordfence Scanner w panelu WordPress, WP-CLI: wp core verify-checksums.

### Jak często robić backup WordPress?

Częstotliwość kopii dobierz do akceptowalnej utraty danych (RPO), a czas odtworzenia do RTO. Sklep z częstymi zamówieniami może wymagać kopii bazy częściej niż raz dziennie; prosta strona rzadziej. Co najmniej jedna kopia powinna być odseparowana od serwera produkcyjnego, a możliwość odtworzenia testowana według uzgodnionego harmonogramu.

### Czy zmiana URL wp-login.php zwiększa bezpieczeństwo?

Zmiana URL może ograniczyć część generycznego ruchu kierowanego na domyślną ścieżkę, ale nie eliminuje brute force ani nie zastępuje 2FA, limitów prób, silnych haseł, aktualizacji i monitoringu. Wtyczkę dobierz po sprawdzeniu zgodności z logowaniem, cache i procesem odzyskiwania dostępu.

### Jak zabezpieczyć wp-config.php?

Plik nie może być publicznie serwowany, a jego uprawnienia powinny być możliwie wąskie dla modelu użytkowników danego hostingu. Przeniesienie poza katalog publiczny bywa jednym z wariantów, lecz zgodność i reguły serwera (Apache/Nginx) trzeba sprawdzić w konkretnej konfiguracji; nie ustawiaj 440 ani dyrektyw .htaccess w ciemno.

### Czy WordPress jest bezpieczny dla sklepu internetowego?

Bezpieczeństwo sklepu zależy od kodu, hostingu, konfiguracji płatności i procedur, a nie tylko od platformy. Zewnętrzna strona płatności lub pola hostowane mogą ograniczyć zakres obsługi danych kart po stronie sklepu, lecz nie zdejmują wszystkich obowiązków PCI DSS z właściciela. Ustal zakres walidacji z operatorem płatności, a w razie potrzeby z właściwym specjalistą; ten poradnik nie jest oceną zgodności.

### Jak usunąć złośliwe oprogramowanie z WordPress?

Odizoluj witrynę, zabezpiecz kopię i logi, ogranicz nieautoryzowany dostęp, ustal przyczynę oraz zakres naruszenia. Odtwórz zaufany kod i dane, zamknij lukę, obróć odpowiednie sekrety i przetestuj działanie. Skaner oraz sumy kontrolne są tylko częścią analizy. Jeśli Search Console wykazało problemy bezpieczeństwa, po pełnej naprawie złóż wniosek o sprawdzenie w tym raporcie — nie samo żądanie indeksowania.