Umów konsultację

Bezpłatna wycena w 24h

Bezpieczeństwo WordPress — checklist, który stosujemy na każdym wdrożeniu

Bezpieczeństwo WordPress — checklist, który stosujemy na każdym wdrożeniu

Narzędzia23 maja 20269 min czytania

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:

Max Mazurkiewicz

Max Mazurkiewicz

Founder

POTRZEBUJESZ SPERSONALIZOWANEJ WYCENY?

Chcesz się na coś zdecydować ale od nadmiaru możliwości boli głowa? Skontaktuj się z nami, dobierzemy rozwiązanie do potrzeb Twojej firmy.

Umów się na konsultację
  • 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ówdefine('DISALLOW_FILE_EDIT', true); w wp-config.php. Nie pozwól nikomu edytować plików wtyczek/motywów z panelu admina.

Headers bezpieczeństwa

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.

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.

Najczęściej zadawane pytania

Sam WordPress (core) jest bezpieczny — ma duży zespół bezpieczeństwa i regularne aktualizacje. Problem to nieaktualizowane wtyczki, słabe hasła i brak 2FA. 80% włamań wykorzystuje znane luki w starych wersjach wtyczek. Poprawnie zabezpieczony WordPress jest tak samo bezpieczny jak każdy inny CMS.

Nie polecam wtyczek all-in-one. Wordfence, Sucuri, iThemes Security to dodatkowe wtyczki z dostępem do całego systemu — same mogą stać się wektorem ataku. Lepiej: firewall na serwerze (fail2ban, Cloudflare WAF), 2FA dedykowaną wtyczką, poprawne uprawnienia plików i regularne aktualizacje.

Core WordPress: auto-update minor (5.9.1→5.9.2) od razu, major (5.9→6.0) ręcznie po testach. Wtyczki: co tydzień, po wykonaniu backupu. PHP: trzymaj minimum wersję 8.1 — starsze nie otrzymują poprawek bezpieczeństwa.

Natychmiast: zmień wszystkie hasła (WP admin, FTP, baza danych, hosting). Przywróć backup sprzed włamania. Przeskanuj pliki na malware (ClamAV, WP-CLI). Zaktualizuj wszystko. Sprawdź, jak doszło do włamania (zwykle stara wtyczka). Jeśli nie masz backupu — zatrudnij specjalistę, nie próbuj czyścić sam.

Max Mazurkiewicz
Max Mazurkiewicz
Founder
Digital marketing expert