Bezpieczeństwo, SSL, CMS, WordPress i nagłówki HTTP

Certyfikat SSL: ważność

Odczytujemy dane certyfikatu SSL Twojej domeny i raportujemy, czy jest ważny i poprawnie wystawiony. Wygasły certyfikat zatrzymuje odwiedzających na ostrzeżeniu przeglądarki, więc pilnujemy terminu z wyprzedzeniem.

Jak to robimy

1. Sprawdzamy wystawcę, datę rozpoczęcia ważności, datę wygaśnięcia i liczbę dni do końca.
2. Weryfikujemy listę domen w polu SAN, czyli adresy objęte certyfikatem, oraz ewentualny wildcard.
3. Odczytujemy algorytm podpisu i długość klucza, żeby ocenić, czy spełniają obecne standardy.
4. Ustawiamy przypomnienie o odnowieniu, jeśli certyfikat nie odnawia się automatycznie.

Co otrzymujesz

W raporcie dostajesz status certyfikatu z datą wygaśnięcia, liczbą pozostałych dni, algorytmem i długością klucza. Wiesz z wyprzedzeniem, kiedy potrzebne jest odnowienie.

Kiedy i w jakiej formie: Tygodniowo/miesięcznie

HTTPS i mixed content

Wymuszamy HTTPS na wszystkich wersjach domeny i usuwamy mixed content, czyli zasoby ładowane przez niezabezpieczony protokół HTTP. Taki obrazek lub skrypt wywołuje ostrzeżenia przeglądarki i może zostać przez nią zablokowany.

Jak to robimy

1. Sprawdzamy, czy wersje z www, bez www i z http trafiają jednym przekierowaniem pod docelowy adres HTTPS.
2. Crawlujemy serwis i liczymy strony, które ładują obrazy, skrypty lub style przez HTTP.
3. Podmieniamy adresy zasobów w bazie danych i szablonach na wersję HTTPS.
4. Poprawiamy linki wewnętrzne, które nadal wskazują adresy zaczynające się od http.

Co otrzymujesz

Cała strona działa pod jednym bezpiecznym adresem, bez ostrzeżeń w przeglądarce. W raporcie podajemy liczbę wykrytych przypadków mixed content przed poprawkami i po nich.

Kiedy i w jakiej formie: Miesięcznie

• Screaming Frog
• Lighthouse
• WordPress

HSTS i nagłówki bezpieczeństwa

Sprawdzamy nagłówki HTTP, którymi serwer instruuje przeglądarkę, jak ma chronić użytkownika. Ich brak ułatwia ataki typu clickjacking, podmianę typu plików i wyciek danych w adresach odsyłających.

Jak to robimy

1. Weryfikujemy HSTS, który wymusza połączenie HTTPS przy kolejnych wizytach w serwisie.
2. Sprawdzamy X-Frame-Options lub dyrektywę frame-ancestors chroniącą przed osadzaniem strony w ramkach.
3. Kontrolujemy X-Content-Type-Options, Referrer-Policy i Permissions-Policy na głównych typach stron.
4. Oceniamy obecność CSP oraz nagłówków izolacji COOP, COEP i CORP.
5. Przygotowujemy dla programistów konfigurację brakujących nagłówków z opisem wpływu na działanie strony.

Co otrzymujesz

Dostajesz tabelę nagłówków bezpieczeństwa ze statusem i gotową konfiguracją do wdrożenia. Po zmianach przeglądarka odwiedzających blokuje najczęstsze techniki ataków na stronę.

Kiedy i w jakiej formie: Kwartalnie

• Lighthouse

Content Security Policy

Wdrażamy Content Security Policy, czyli nagłówek określający, z jakich źródeł strona może ładować skrypty i inne zasoby. Zaczynamy od trybu report-only, który tylko zgłasza naruszenia i niczego nie blokuje.

Jak to robimy

1. Spisujemy wszystkie zewnętrzne źródła skryptów, stylów, czcionek i ramek używane w serwisie.
2. Uruchamiamy politykę w trybie report-only i przez okres testowy zbieramy raporty naruszeń.
3. Ograniczamy użycie eval i skryptów inline, przenosząc kod do plików lub stosując znaczniki nonce.
4. Po testach włączamy tryb blokujący i aktualizujemy listę dozwolonych dostawców przy nowych integracjach.

Co otrzymujesz

Strona ma działającą politykę CSP, która utrudnia wstrzyknięcie obcego skryptu. W raporcie zaznaczamy, czy CSP jest wdrożona, i przekazujemy listę dozwolonych źródeł.

Kiedy i w jakiej formie: Kwartalnie + po deployach

• Google Tag Manager

SRI dla CDN i third-party JS

Dla skryptów pobieranych z zewnętrznych serwerów wdrażamy Subresource Integrity. To skrót kryptograficzny, który przeglądarka porównuje z pobranym plikiem. Jeśli ktoś podmieni skrypt u dostawcy, przeglądarka go nie wykona.

Jak to robimy

1. Wyszukujemy w kodzie skrypty i style ładowane z CDN oraz od dostawców zewnętrznych.
2. Sprawdzamy, które z nich mają stałe wersje i nadają się do zabezpieczenia skrótem.
3. Generujemy atrybuty integrity i crossorigin, a następnie dodajemy je do znaczników w szablonie.
4. Ustalamy proces aktualizacji skrótu przy każdej zmianie wersji zewnętrznej biblioteki.

Co otrzymujesz

Zewnętrzne biblioteki ładują się tylko w zweryfikowanej wersji. W raporcie zaznaczamy, czy SRI jest wdrożone, i wskazujemy skrypty, których nie da się tak zabezpieczyć.

Kiedy i w jakiej formie: Kwartalnie

WordPress: aktualność silnika, motywów i wtyczek

Raportujemy stan oprogramowania Twojego WordPressa: wersję silnika, motywu i wszystkich wtyczek. Przestarzałe komponenty to najczęstsza furtka dla włamań na strony oparte na tym CMS.

Jak to robimy

1. Odczytujemy wersję WordPressa i porównujemy ją z najnowszym wydaniem.
2. Tworzymy listę wtyczek i motywów z dostępnymi aktualizacjami oraz datą ostatniej aktualizacji.
3. Oznaczamy wtyczki porzucone przez autorów i takie, dla których zgłoszono podatności.
4. Sprawdzamy znane konflikty między wtyczkami a wersją PHP na serwerze.
5. Proponujemy kolejność aktualizacji, zaczynając od komponentów ze zgłoszonymi lukami bezpieczeństwa.

Co otrzymujesz

Dostajesz raport z wersją WordPressa, listą wtyczek do aktualizacji i rekomendacją dla porzuconych dodatków. Na tej podstawie planujemy bezpieczną kolejność prac.

Kiedy i w jakiej formie: Tygodniowo/miesięcznie

• WordPress

Backupy i test przywracania

Weryfikujemy, czy kopie zapasowe Twojej strony naprawdę istnieją i czy da się z nich skorzystać. Oceniamy ich regularność, miejsce przechowywania i szyfrowanie. Pytamy też, czy ktoś kiedykolwiek przetestował odtworzenie.

Jak to robimy

1. Sprawdzamy datę ostatniej kopii i harmonogram tworzenia kolejnych.
2. Ustalamy, czy kopie leżą poza serwerem produkcyjnym i czy są zaszyfrowane.
3. Jeśli testu przywracania nie było, wykonujemy go na osobnym środowisku testowym.
4. Opisujemy luki w procesie i proponujemy ustawienia, które je zamkną.

Co otrzymujesz

W raporcie widzisz datę ostatniej kopii i wynik testu przywracania. Jeśli czegoś brakuje, dostajesz listę zmian do wprowadzenia w harmonogramie lub miejscu przechowywania kopii.

Kiedy i w jakiej formie: Tygodniowo/miesięcznie

• WordPress

Dostępy, RBAC i 2FA

Wymuszamy bezpieczne logowanie do CMS przez 2FA albo SSO, czyli jedno firmowe konto do wielu systemów. Uprawnienia układamy w modelu RBAC, czyli kontroli dostępu opartej na rolach, z zasadą minimalnych uprawnień.

Jak to robimy

1. Przeprowadzamy audyt kont w CMS, na serwerze i w panelach powiązanych usług.
2. Usuwamy nieaktywnych użytkowników i zawężamy uprawnienia do zakresu potrzebnego w pracy.
3. Włączamy 2FA lub logowanie przez SSO dla wszystkich kont z dostępem do panelu.
4. Ustalamy harmonogram rotacji haseł, kluczy API i kluczy dostępowych do serwera.

Co otrzymujesz

Dostajesz listę kont z rolami, metodą logowania i datą ostatniej zmiany hasła lub klucza. Samo przejęte hasło nie wystarcza już do zalogowania się do panelu.

Kiedy i w jakiej formie: Kwartalnie

• WordPress

Ograniczenie prób logowania i brute force

Zabezpieczamy formularz logowania przed atakami brute force, czyli masowym zgadywaniem haseł przez boty. Ograniczamy liczbę prób, blokujemy podejrzane adresy IP i dodajemy weryfikację CAPTCHA.

Jak to robimy

1. Ustawiamy limit nieudanych logowań i czas blokady po jego przekroczeniu.
2. Włączamy blokowanie adresów IP, z których przychodzi seria nieudanych prób.
3. Dodajemy CAPTCHA do formularza logowania i dobieramy próg oceny ryzyka w wersji niewidocznej.
4. Konfigurujemy wtyczkę bezpieczeństwa albo regułę WAF, która zatrzymuje ruch botów przed dotarciem do WordPressa.

Co otrzymujesz

Panel logowania jest chroniony przed zautomatyzowanym zgadywaniem haseł, a serwer nie jest nim obciążany. W raporcie podajemy ustawiony limit logowania i próg CAPTCHA.

Kiedy i w jakiej formie: Miesięcznie

• WordPress

XML-RPC, .htaccess i katalogi

Blokujemy XML-RPC, jeśli Twoja strona z niego nie korzysta, bo ten interfejs bywa używany do ataków na hasła. Ograniczamy też dostęp do katalogów i plików, które nie powinny być widoczne z przeglądarki.

Jak to robimy

1. Sprawdzamy, czy aplikacje mobilne lub integracje używają XML-RPC, zanim go wyłączymy.
2. Wyłączamy listowanie katalogów w pliku .htaccess albo w konfiguracji serwera nginx.
3. Blokujemy bezpośredni dostęp do pliku wp-config.php, archiwów kopii zapasowych i logów.
4. Wyłączamy edycję plików motywu i wtyczek z poziomu panelu WordPressa.

Co otrzymujesz

Wrażliwe pliki i katalogi są niedostępne z zewnątrz, a nieużywany interfejs XML-RPC nie przyjmuje żądań. Zmiany opisujemy w raporcie z informacją, gdzie zostały wprowadzone.

Kiedy i w jakiej formie: Kwartalnie

• WordPress

WAF, DDoS i bad bots

Oceniamy, jak Twoja strona broni się przed atakami DDoS i szkodliwymi botami. Sprawdzamy, czy działa WAF, czyli zapora aplikacji webowej, zwykle uruchamiana na poziomie CDN.

Jak to robimy

1. Weryfikujemy obecność WAF i reguł ochrony przed atakami przeciążeniowymi.
2. Analizujemy logi serwera, żeby oszacować udział złych botów w odwiedzinach.
3. Sprawdzamy ustawienia rate limiting, czyli limitu zapytań z jednego adresu.
4. Kontrolujemy ochronę przed hotlinkingiem, czyli wykorzystywaniem Twoich obrazów na cudzych stronach.
5. Upewniamy się, że reguły nie odcinają Googlebota ani innych potrzebnych robotów.

Co otrzymujesz

W raporcie zaznaczamy, czy strona ma WAF, i opisujemy luki w ochronie przed botami. Dostajesz rekomendacje ustawień, które zmniejszają obciążenie serwera przez niechciany ruch.

Kiedy i w jakiej formie: Miesięcznie/kwartalnie

• Google Search Console

Serwer i infrastruktura

Opisujemy stan serwera, na którym działa Twoja strona: wersje oprogramowania, protokoły i wskaźniki wydajności. Przestarzałe PHP lub serwer WWW to ryzyko bezpieczeństwa, a wolna odpowiedź serwera spowalnia każdą podstronę.

Jak to robimy

1. Odczytujemy wersje PHP, Node, Apache lub Nginx i porównujemy je z wersjami wspieranymi.
2. Sprawdzamy obsługę HTTP/2 i HTTP/3 oraz konfigurację dostępu przez SSH.
3. Mierzymy TTFB, czyli czas do pierwszego bajtu odpowiedzi, na głównych typach stron.
4. Przeglądamy logi błędów i statusy 5xx, szukając powtarzających się awarii.

Co otrzymujesz

Dostajesz opis infrastruktury z listą elementów do aktualizacji i poprawy. Rekomendacje możesz przekazać bezpośrednio firmie hostingowej lub administratorowi serwera.

Kiedy i w jakiej formie: Kwartalnie

• PageSpeed Insights
• Google Search Console