WordPress to 43% internetu — i cel numer jeden dla botów skanujących luki. Nie dlatego, że WordPress jest niebezpieczny. Dlatego, że większość instalacji jest źle zabezpieczona: domyślny login admin, brak 2FA, nieaktualizowane wtyczki i zero monitoringu. Poniżej opisujemy checklist bezpieczeństwa, który stosujemy na każdym wdrożeniu — bez wtyczek all-in-one typu Wordfence czy Sucuri, które same stają się wektorem ataku (kolejna wtyczka z dostępem do całego systemu).
Aktualizacje — najważniejsza warstwa obrony
80% włamań do WordPressa wykorzystuje znane luki w nieaktualizowanych wtyczkach. Nie zero-day, nie wyrafinowane ataki — po prostu stare wersje wtyczek z opublikowanymi CVE.
Nasza polityka aktualizacji:
- Core WordPress — auto-update minor (5.9.1 → 5.9.2) włączony. Major (5.9 → 6.0) — ręcznie po testach na staging.
- Wtyczki — auto-update dla wtyczek bezpieczeństwa (firewall, 2FA). Pozostałe — ręcznie co tydzień. Przed aktualizacją: backup bazy i plików.
- Motywy — jeśli custom motyw — nie dotyczy. Jeśli gotowy motyw — aktualizacja jak wtyczki.
- PHP — minimum PHP 8.1. Starsze wersje (7.4, 8.0) nie otrzymują już poprawek bezpieczeństwa.
Logowanie — ukrycie i zabezpieczenie wp-login
Domyślny /wp-login.php to zaproszenie dla brute-force botów. Co robimy:
- Zmiana URL logowania — przenosimy /wp-login.php na niestandardowy adres (np. /panel-logowania). Nie przez wtyczkę — przez prostą regułę w .htaccess lub nginx config.
- 2FA (dwuskładnikowe uwierzytelnianie) — obowiązkowe dla każdego konta admina. Używamy WP 2FA lub miniOrange. Google Authenticator, nie SMS (SMS jest podatny na SIM swapping).
- Limit prób logowania — maksimum 5 prób na 15 minut. Po przekroczeniu — blokada IP na 1 godzinę. Konfiguracja w .htaccess lub fail2ban na serwerze.
- Wyłączenie XML-RPC — XML-RPC to stary protokół, który pozwala na zdalne logowanie. Jeśli nie używasz aplikacji mobilnej WordPress — wyłącz:
<Files xmlrpc.php> Deny from all </Files>
Uprawnienia plików i katalogów
Złe uprawnienia plików to otwarte drzwi. Checklist:
- wp-config.php — uprawnienia 400 (tylko odczyt dla właściciela). Przenieś powyżej public_html jeśli hosting pozwala.
- Katalogi — 755 (właściciel: rwx, reszta: rx). Nigdy 777.
- Pliki — 644 (właściciel: rw, reszta: r). Nigdy 666.
- .htaccess — 444 (tylko odczyt dla wszystkich). Zmiana uprawnień tylko na czas edycji.
- Wyłączenie edytora plików —
define('DISALLOW_FILE_EDIT', true); w wp-config.php. Nie pozwól nikomu edytować plików wtyczek/motywów z panelu admina.
Nagłówki HTTP, które dodajemy na każdym wdrożeniu (w .htaccess lub nginx):
- Content-Security-Policy — kontroluje, skąd przeglądarka może ładować zasoby. Blokuje XSS i inlineowe skrypty z injectowanych treści.
- X-Frame-Options: DENY — blokuje osadzanie strony w iframe (ochrona przed clickjackingiem).
- X-Content-Type-Options: nosniff — zapobiega MIME type sniffing.
- Strict-Transport-Security — wymusza HTTPS.
max-age=31536000; includeSubDomains.
- Permissions-Policy — kontroluje dostęp do API przeglądarki (kamera, mikrofon, geolokalizacja). Wyłączamy wszystko, czego strona nie używa.
Backup i monitoring
Zabezpieczenie to nie tylko zapobieganie — to też szybka reakcja i odtwarzanie:
- Backup automatyczny — codziennie, na osobny serwer (nie na ten sam hosting). Używamy UpdraftPlus z przechowywaniem na S3 lub Google Drive. Retencja: 14 dni.
- Monitoring uptime — UptimeRobot (darmowy) sprawdza co 5 minut, czy strona odpowiada. Alert SMS/email przy przestoju.
- Monitoring zmian plików — skrypt porównujący checksumy plików co 24h. Zmiana w core WordPress lub w pliku wtyczki bez aktualizacji = potencjalne włamanie.
- Skanowanie malware — raz w tygodniu skan plików na serwerze (ClamAV lub WP-CLI --checksum). Nie polegamy na wtyczkach bezpieczeństwa — skanujemy z poziomu serwera.
Z naszej praktyki — jak konfigurujemy bezpieczeństwo realnych wdrożeń
Konkretne przykłady konfiguracji bezpieczeństwa z naszych produkcyjnych wdrożeń WordPress:
- RehaFit — centrum fizjoterapii z systemem zapisów online i bazą pacjentów. Custom motyw bez Elementora (mniejsza powierzchnia ataku), 2FA dla wszystkich kont administracyjnych, ukrycie /wp-login, codzienne backupy na osobny serwer (zasada „backup nigdy na tym samym serwerze co produkcja"), Redis Object Cache jako warstwa wydajnościowa nieotwierająca dodatkowych portów.
- Żłobek i Przedszkole Jagódka — strona placówki edukacyjnej z formularzami zapisów dzieci (dane wrażliwe RODO). Wzmocniona walidacja formularzy, ograniczenie liczby prób zapisów per IP, automatyczne szyfrowanie danych zapisów przed wysłaniem do CRM, monitoring nieudanych prób dostępu do panelu.
- Nobobobo i Podsztanga — sklepy WooCommerce ze sprzedażą online. Wyłączenie edytora plików z panelu admina (
DISALLOW_FILE_EDIT), uprawnienia 400 dla wp-config.php, ograniczenie pluginów do absolutnego minimum (każda wtyczka to potencjalne CVE), Cloudflare WAF przed całym stackiem.
Wzorzec we wszystkich przypadkach jest identyczny: minimalna powierzchnia ataku + monitoring + regularne backupy. Nie ma magicznej wtyczki, która zastąpi te trzy elementy.
Bezpieczeństwo to proces, nie produkt. Żadna wtyczka nie zastąpi poprawnej konfiguracji serwera, regularnych aktualizacji i monitoringu. Jeśli potrzebujesz audytu bezpieczeństwa lub stałego wsparcia IT — zabezpieczamy strony WordPress w ramach opieki technicznej.
