WordPress napędza ponad 40% internetu, co czyni go preferowanym celem zautomatyzowanych ataków. Dobra wiadomość: większość udanych hacków WordPress wykorzystuje znane, łatwe do uniknięcia luki. Ta lista kontrolna przeprowadzi Cię przez każdą warstwę bezpieczeństwa WordPress, od szyfrowania transportowego po hardening na poziomie serwera. Przepracuj ją systematycznie, a Twoja witryna będzie znacznie trudniejsza do skompromitowania niż zdecydowana większość instalacji WordPress.
Zabezpieczanie witryny WordPress za pomocą SSL i HTTPS
HTTPS szyfruje wszystkie dane przesyłane między przeglądarkami odwiedzających a Twoim serwerem. Bez niego dane uwierzytelniające, zgłoszenia formularzy i cookie sesji są wysyłane w postaci tekstu jawnego, co czyni je trywialnymi do przechwycenia w sieciach publicznych.
- Zainstaluj ważny certyfikat SSL: Większość hostingodawców oferuje darmowe certyfikaty Let's Encrypt automatycznie odnawiane co 90 dni. Jeśli Twój host nie obsługuje Let's Encrypt, darmowy plan Cloudflare zawiera współdzielony certyfikat SSL. Nie ma powodu, aby w 2025 działać bez HTTPS.
- Przekieruj cały ruch HTTP na HTTPS: Skonfiguruj przekierowanie 301, aby każde żądanie do
http://było trwale przekierowywane nahttps://. Na Apache dodaj to do.htaccess:
Na Nginx dodaj blok server, który przekierowuje:RewriteEngine On RewriteCond %{HTTPS} off RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]server { listen 80; server_name example.com www.example.com; return 301 https://$host$request_uri; } - Rozwiąż wszystkie ostrzeżenia mixed content: Po przełączeniu na HTTPS sprawdź obrazy, skrypty lub arkusze stylów, które nadal ładują się przez HTTP. Konsola przeglądarki oznacza je jako ostrzeżenia "Mixed Content". Zaktualizuj zakodowane URL-e
http://w bazie danych za pomocą narzędzia wyszukaj-i-zastąp, takiego jak Better Search Replace. - Włącz nagłówek HSTS: HTTP Strict Transport Security mówi przeglądarkom, aby zawsze używały HTTPS dla Twojej domeny, nawet jeśli użytkownik ręcznie wpisze
http://. Dodaj ten nagłówek z max-age co najmniej sześciu miesięcy (15768000 sekund). WłączincludeSubDomainstylko wtedy, gdy wszystkie Twoje subdomeny również obsługują HTTPS.
Konfiguracja nagłówków bezpieczeństwa HTTP dla WordPress
Nagłówki bezpieczeństwa to instrukcje, które Twój serwer wysyła do przeglądarki. Nic nie kosztują pod względem wydajności, ale zapewniają znaczną ochronę przed typowymi wektorami ataków, takimi jak clickjacking, zamieszanie typu MIME i cross-site scripting.
- X-Frame-Options: SAMEORIGIN: Zapobiega osadzaniu Twoich stron w ramkach na innych domenach. Blokuje to ataki clickjacking, w których atakujący nakłada na Twoją witrynę niewidoczne elementy, aby skłonić użytkowników do kliknięcia czegoś, czego nie zamierzali.
- X-Content-Type-Options: nosniff: Zatrzymuje przeglądarki przed zgadywaniem typu MIME pliku. Bez tego nagłówka przeglądarka może wykonać plik tekstowy jako JavaScript, jeśli treść wygląda jak kod, otwierając drzwi do wstrzykiwania skryptów.
- Referrer-Policy: strict-origin-when-cross-origin: Kontroluje, ile informacji URL jest wysyłanych podczas nawigacji do witryn zewnętrznych. Zapobiega to wyciekowi wrażliwych parametrów URL (takich jak tokeny resetowania hasła) do serwerów stron trzecich.
- Permissions-Policy: Ogranicza dostęp do funkcji przeglądarki, takich jak kamera, mikrofon, geolokalizacja i API płatności dla osadzonej zawartości. Nawet jeśli nie używasz tych funkcji, ustawienie polityki zapobiega ich nadużywaniu przez wstrzyknięte skrypty.
- Content-Security-Policy (CSP): Najpotężniejszy nagłówek bezpieczeństwa, ale także najbardziej skomplikowany w konfiguracji. CSP definiuje, jakie źródła skryptów, stylów, obrazów i innych zasobów mogą być ładowane. Zacznij od
Content-Security-Policy-Report-Only, aby monitorować naruszenia bez psucia witryny, a następnie stopniowo zacieśniaj politykę. Minimalny punkt wyjścia:Content-Security-Policy: default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data:;
Możesz ustawić te nagłówki w pliku .htaccess (Apache), konfiguracji Nginx lub przez wtyczkę bezpieczeństwa WordPress. Jeśli używasz Cloudflare, większość z nich możesz również skonfigurować w Security > Settings.
Techniki hardeningu rdzenia WordPress
Sam WordPress jest dobrze utrzymywany i regularnie łatany, ale domyślna konfiguracja pozostawia kilka drzwi otwartych, które musisz świadomie zamknąć.
- Aktualizuj rdzeń WordPress, wtyczki i motywy: Większość hacków WordPress wykorzystuje znane luki w przestarzałym oprogramowaniu. Włącz automatyczne aktualizacje minor (są domyślnie włączone) i sprawdzaj aktualizacje major co najmniej raz w tygodniu. Rozważ automatyczne aktualizacje wtyczek dla zaufanych wtyczek.
- Usuń całkowicie nieużywane wtyczki i motywy: Dezaktywacja wtyczki nie usuwa kodu z serwera. Atakujący nadal może wykorzystać luki w dezaktywowanych wtyczkach. Usuń wszystko, czego aktywnie nie używasz, i zachowaj tylko jeden domyślny motyw jako zapasowy.
- Wyłącz XML-RPC: Interfejs XML-RPC (
/xmlrpc.php) został zaprojektowany do zdalnego publikowania i pingbacków. Dziś jest głównie nadużywany do ataków brute-force amplification i DDoS. Chyba że potrzebujesz go dla Jetpack lub aplikacji mobilnej WordPress, wyłącz go całkowicie. Możesz go zablokować na poziomie serwera:# Apache .htaccess <Files xmlrpc.php> Order Deny,Allow Deny from all </Files> - Ogranicz punkt końcowy użytkowników REST API: Domyślnie
/wp-json/wp/v2/usersujawnia nazwy użytkowników każdemu. Czyni to trywialnym dla atakujących odkrycie ważnych nazw logowania. Ogranicz ten punkt końcowy tylko do żądań uwierzytelnionych, używając wtyczki lub niestandardowego fragmentu kodu. - Blokuj wyliczanie użytkowników przez archiwa autorów: Nawet bez REST API atakujący mogą odkryć nazwy użytkowników, prosząc o
/?author=1,/?author=2, itd. Zablokuj to, przekierowując żądania do archiwów autorów lub całkowicie je wyłączając, jeśli Twoja witryna ich nie potrzebuje. - Usuń numer wersji WordPress: WordPress wyświetla swoją wersję w meta tagu oraz w URL-ach plików CSS/JS rdzenia. Choć samo zabezpieczenie przez ukrycie jest niewystarczające, usunięcie numeru wersji zmusza atakujących do badania, zamiast po prostu wyszukiwania znanych luk dla Twojej dokładnej wersji.
- Zabezpiecz lub usuń plik debug.log: Gdy
WP_DEBUG_LOGjest włączone, WordPress zapisuje błędy do/wp-content/debug.log. Ten plik może zawierać zapytania bazy danych, ścieżki plików, błędy wtyczek i inne informacje przydatne dla atakujących. Nigdy nie pozostawiaj logowania debug włączonego w produkcji, a jeśli plik istnieje, usuń go lub zablokuj do niego dostęp. - Używaj silnych, unikalnych haseł i włącz uwierzytelnianie dwuskładnikowe: Każde konto WordPress powinno mieć hasło co najmniej 16 znaków i unikalne dla tej witryny. Dodaj uwierzytelnianie dwuskładnikowe (2FA) za pomocą wtyczki takiej jak WP 2FA lub Wordfence Login Security. Sam ten środek blokuje praktycznie wszystkie ataki brute-force.
- Ogranicz próby logowania: WordPress domyślnie pozwala na nieograniczone próby logowania. Użyj wtyczki takiej jak Limit Login Attempts Reloaded, aby blokować adresy IP po kilku nieudanych próbach, lub użyj Web Application Firewall (WAF) z ochroną przed brute-force.
- Zmień domyślny prefiks tabel bazy danych: WordPress używa
wp_jako domyślnego prefiksu tabel. Zmiana go na coś unikalnego podczas instalacji nieco utrudnia zautomatyzowane ataki SQL injection. Jeśli Twoja witryna jest już aktywna, nadal możesz to zmienić, ale najpierw wykonaj kopię zapasową bazy danych.
Uprawnienia plików WordPress i bezpieczeństwo serwera
Uprawnienia plików kontrolują, kto może czytać, zapisywać i wykonywać pliki na serwerze. Nieprawidłowe uprawnienia są jedną z najczęstszych błędnych konfiguracji bezpieczeństwa.
- Ustaw poprawne uprawnienia plików: Użyj 644 dla plików i 755 dla katalogów. Plik
wp-config.phppowinien być ustawiony na 600 lub 640 w większości środowisk hostingowych. Nigdy nie używaj 777, które daje pełny dostęp do odczytu/zapisu/wykonywania każdemu. - Chroń wp-config.php przed dostępem z sieci: Ten plik zawiera dane uwierzytelniające bazy danych, klucze uwierzytelniania i salty. Na Apache dodaj to do
.htaccess:
Niektóre przewodniki bezpieczeństwa sugerują przeniesienie<Files wp-config.php> Order Allow,Deny Deny from all </Files>wp-config.phpjeden katalog powyżej webroot. Działa to w większości konfiguracji, ale może powodować problemy u niektórych hostingodawców. - Wyłącz wbudowany edytor plików: WordPress zawiera edytor plików w panelu administracyjnym, który pozwala administratorom modyfikować pliki motywów i wtyczek bezpośrednio. Jeśli atakujący uzyska prawa administratora, ten edytor daje mu możliwość wstrzyknięcia złośliwego kodu w dowolny plik PHP. Wyłącz go, dodając tę linię do
wp-config.php:define('DISALLOW_FILE_EDIT', true); - Blokuj dostęp do wrażliwych plików: Pliki takie jak
readme.html,license.txtiwp-config-sample.phpujawniają informacje o wersji i konfiguracji WordPress. Zablokuj publiczny dostęp do nich przez konfigurację serwera. - Wyłącz przeglądanie katalogów: Jeśli wyświetlanie katalogów jest włączone, każdy może przeglądać Twój katalog
/wp-content/uploads/i zobaczyć każdy plik, który przesłałeś. Wyłącz to, dodającOptions -Indexesdo.htaccess.
Strategia kopii zapasowych WordPress i planowanie odzyskiwania
Żadna instalacja bezpieczeństwa nie jest kompletna bez niezawodnej strategii kopii zapasowych. Jeśli wydarzy się najgorsze, niedawna kopia zapasowa to różnica między drobną niedogodnością a całkowitą stratą.
- Automatyzuj codzienne kopie zapasowe: Użyj wtyczki takiej jak UpdraftPlus, BlogVault lub BackWPup, aby uruchamiać automatyczne kopie zapasowe według harmonogramu. Twórz kopie zapasowe co najmniej codziennie. Witryny o dużym ruchu lub sklepy WooCommerce powinny rozważyć kopie zapasowe w czasie rzeczywistym.
- Przechowuj kopie zapasowe off-site: Przechowuj kopie w usłudze zewnętrznej, takiej jak Amazon S3, Google Cloud Storage lub Dropbox. Jeśli Twój serwer zostanie skompromitowany, lokalne kopie zapasowe również mogą być dotknięte.
- Testuj proces odzyskiwania: Kopia zapasowa, której nigdy nie testowałeś, to kopia zapasowa, której nie możesz zaufać. Przywróć kopię zapasową przynajmniej raz na kwartał w środowisku staging, aby potwierdzić, że działa.
- Zachowuj wiele generacji kopii zapasowych: Zachowaj co najmniej 30 dni codziennych kopii zapasowych. Niektóre infekcje pozostają niewykryte przez tygodnie, więc potrzebujesz możliwości cofnięcia się do znanego czystego stanu.
Ciągły monitoring bezpieczeństwa WordPress
Bezpieczeństwo nie jest jednorazowym projektem. Nowe luki są regularnie odkrywane, a konfiguracja Twojej witryny może z czasem ulegać zmianom w miarę dodawania wtyczek lub zmiany ustawień.
- Zainstaluj wtyczkę bezpieczeństwa: Wordfence, Sucuri lub NinjaFirewall zapewniają ochronę w czasie rzeczywistym, w tym reguły firewall, skanowanie złośliwego oprogramowania i bezpieczeństwo logowania. Wybierz jedną (nie wiele, ponieważ mogą się konfliktować) i skonfiguruj jej alerty.
- Skonfiguruj automatyczne skany InspectWP: Zaplanuj regularne skany, aby monitorować swoją postawę bezpieczeństwa w czasie. InspectWP ostrzega Cię o nowych problemach, takich jak brakujące nagłówki, ujawnione logi debug lub wycieki numerów wersji, gdy tylko się pojawią.
- Włącz powiadomienia o aktualizacjach: Upewnij się, że WordPress wysyła Ci powiadomienia e-mail, gdy dostępne są aktualizacje rdzenia, wtyczek lub motywów. Łatki bezpieczeństwa często muszą być wdrożone w ciągu kilku godzin od wydania, aby wyprzedzić zautomatyzowane exploity.
- Regularnie przeglądaj konta użytkowników: Usuwaj nieaktywne konta, zwłaszcza te z rolami administratora lub redaktora. Audytuj listę użytkowników co najmniej raz w miesiącu i natychmiast cofaj dostęp każdemu, kto już go nie potrzebuje.
- Monitoruj swoje logi dostępu: Sprawdzaj logi serwera pod kątem nietypowych wzorców, takich jak powtarzające się żądania do
/wp-login.php,/xmlrpc.phplub ścieżek, które nie istnieją. Wiele wtyczek bezpieczeństwa zapewnia uproszczony widok logów.
Zweryfikuj swoje bezpieczeństwo WordPress za pomocą InspectWP
Uruchom kompleksowy skan InspectWP, aby sprawdzić wszystkie elementy związane z bezpieczeństwem za jednym razem. Sekcja bezpieczeństwa obejmuje konfigurację SSL, nagłówki bezpieczeństwa HTTP, ujawnienie wersji WordPress, wyliczanie użytkowników REST API, dostępność logu debug i więcej. Skonfiguruj automatyczne skany, aby otrzymywać powiadomienia, gdy zmienia się Twoja postawa bezpieczeństwa, dzięki czemu możesz rozwiązywać nowe problemy, zanim zostaną wykorzystane.