Najważniejsze wnioski
- 80% udanych ataków na małe firmy wynika z braku aktualizacji lub słabych haseł bez 2FA — to najłatwiej naprawić.
- WAF i ochrona przed botami to nie dodatek dla korporacji — dostępne są konfiguracje CDN/chmurowe od kilkudziesięciu złotych miesięcznie.
- Backup bez testu odtwarzania to iluzja zabezpieczenia — raz na kwartał sprawdź, czy da się z niego skorzystać.
- Zasada najmniejszych uprawnień i separacja kont chroni przed eskalacją ataku nawet po naruszeniu jednego konta.
- Jeśli chcesz wdrożyć te zasady u siebie, sprawdź ofertę audytu bezpieczeństwa.
1. Aktualizacje — pierwsza linia obrony
Większość ataków na strony WordPress nie korzysta z zaawansowanych technik. Exploitują znane luki w wtyczkach lub starych wersjach CMS, które mają publicznie dostępne PoC (proof of concept). Boty skanują w poszukiwaniu określonych wersji oprogramowania, a nie konkretnych celów. Ustal proces: kto odpowiada za aktualizacje, jak często i jak testuje po aktualizacji. Harmonogram raz na 2 tygodnie to minimum.
2. Silne logowanie: 2FA i unikalne hasła
Credential stuffing — atak polegający na próbowaniu par login/hasło z wycieków innych serwisów — jest odpowiedzialny za dużą część przejęć paneli. Jeśli używasz tego samego hasła co w innym serwisie, a tamten serwis miał wyciek, Twoje hasło jest w bazach atakujących.
- 2FA dla panelu admina i kont email — aplikacja uwierzytelniająca (np. Aegis, Google Authenticator), nie SMS.
- Menedżer haseł (Bitwarden, 1Password) i unikalne hasło dla każdego serwisu.
- Limit prób logowania (anti-bruteforce) — po 5 błędnych próbach blokada IP lub CAPTCHA.
3. WAF i ochrona przed botami
Web Application Firewall analizuje ruch przed dotarciem do serwera i blokuje typowe ataki: SQLi, XSS, skanowanie podatności. Dla większości stron wystarczy konfiguracja na poziomie CDN (np. Cloudflare Free) z włączonymi regułami zarządzanymi. Pełne WAF-y klasy enterprise kosztują tysiące miesięcznie, ale podstawowa ochrona jest dostępna bezpłatnie lub za kilkadziesiąt złotych.
4. Backupy, które da się odtworzyć
Backup, którego nigdy nie testowałeś, nie istnieje. To banalne, ale wiele firm dowiaduje się o problemach z backupem dopiero podczas incydentu — kiedy jest już za późno.
- Backup plików i bazy danych w osobnych miejscach (nie tylko na tym samym serwerze).
- Rotacja: dzienne backupy przez 7 dni, tygodniowe przez 30 dni, miesięczne przez 90 dni.
- Test odtwarzania raz na kwartał: rzeczywiście przywróć stronę na środowisku testowym i sprawdź, czy działa.
5. Formularze i email — niedoceniany wektor
Formularz bez walidacji serwerowej to zaproszenie. JS-owa walidacja po stronie klienta może blokować zwykłego użytkownika, ale atakujący pomija ją trivialnie. Walidacja po stronie serwera jest obowiązkowa. Dodaj do tego honeypot (ukryte pole, które bot wypełnia, a człowiek nie widzi) i rate limiting (max X zgłoszeń na minutę z jednego IP) — to eliminuje 90% spamu i prób wstrzyknięcia.
6. Monitoring i szybka reakcja
Najgroźniejsze incydenty to te, które trwają tygodniami zanim ktoś je zauważy. Malware wstrzyknięty do strony zbierający dane formularzy, serwer rozsyłający spam, konta z obniżoną reputacją emailową. Minimum: monitoring uptime (np. Better Uptime lub UptimeRobot — bezpłatnie), alert bezpieczeństwa w CMS i logowanie błędów 500 na serwerze.
7. Nagłówki bezpieczeństwa i CSP
Nagłówki HTTP takie jak X-Frame-Options, X-Content-Type-Options i Referrer-Policy to kilka linii w konfiguracji serwera, które eliminują całe klasy ataków (clickjacking, MIME sniffing). Content Security Policy (CSP) wymaga więcej pracy, ale znacząco utrudnia XSS — warto wdrożyć przynajmniej tryb raportowania, żeby zobaczyć, co jest blokowane.
8. Zasada najmniejszych uprawnień
Każde konto — administratora strony, bazy danych, serwera FTP — powinno mieć tylko te uprawnienia, których faktycznie potrzebuje. Konto, które tylko wyświetla treści, nie powinno mieć dostępu do edycji ani instalacji wtyczek. Konto bazodanowe dla aplikacji nie powinno mieć uprawnień do DROP TABLE. To ogranicza skutki kompromitacji: nawet jeśli atakujący przejmie jedno konto, nie eskaluje na całą infrastrukturę.
9. HTTPS, HSTS i wymuszenie przekierowań
Certyfikat SSL to standard, ale samo jego posiadanie nie wystarczy. Upewnij się, że HTTP jest trwale przekierowywane na HTTPS (301, nie 302), oraz wdróż nagłówek HSTS (Strict-Transport-Security: max-age=31536000) — to mówi przeglądarce, żeby zawsze korzystała z HTTPS dla Twojej domeny, bez możliwości downgrade'u. Szczegóły: Dlaczego SSL to za mało.
10. Ochrona uploadów i skanowanie malware
Jeśli strona przyjmuje pliki od użytkowników (zdjęcia profilowe, dokumenty, portfolio) — to potencjalny wektor ataku. Filtruj typy plików po stronie serwera (nie tylko po rozszerzeniu, ale po MIME type), skanuj przesłane pliki antywirusem przed udostępnieniem i nigdy nie serwuj uploadów z głównej domeny (osobna subdomena lub CDN). Dla WordPress: narzędzia jak Wordfence lub MalCare mogą skanować pliki automatycznie.
Chcesz wiedzieć, gdzie jesteś narażony?
Sprawdzimy podatności, konfigurację serwera i ryzyka — i przygotujemy listę działań naprawczych z priorytetami. Bez ogólnych rekomendacji.