Jak czytać raport bezpieczeństwa strony — bez paniki | Scanthra

Scanthra · 7 min czytania · Zaktualizowano Maj 2026

Dlaczego takie raporty na początku wydają się przerażające

Większość raportów bezpieczeństwa była pisana oryginalnie przez testerów penetracyjnych dla innych testerów. Używają słów takich jak „wektor", „podatne przejęcie subdomeny", „brakujący preload HSTS (wymuszanie HTTPS)", jakby wszyscy czytali je przy porannej kawie. Jeśli prowadzisz małą stronę i właśnie otworzyłeś(-aś) PDF pełen czerwonych ramek, naturalna reakcja to panika, a potem zamknięcie karty.

Nie zamykaj. Niemal każdy nowoczesny raport — w tym raporty Scanthra — ma tę samą strukturę pod warstwą stylistyczną i gdy wiesz, czego szukać, możesz go przeczytać w około dziesięć minut.

Cztery rzeczy, które mówi każde wykrycie

1. Poziom zagrożenia — jak poważne to jest w teorii?

Poziom zagrożenia to największy możliwy skutek, jeśli problem jest prawdziwy i ktoś go wykorzysta. Niemal zawsze stosuje się pięć poziomów:

• KRYTYCZNE — bezpośrednia, natychmiastowa szkoda. Przykłady: plik .env z hasłami do bazy dostępny publicznie; subdomena możliwa do przejęcia przez atakującego w celu hostowania phishingu. Potraktuj jako naprawić dziś.
• WYSOKIE — poważne, ale nie natychmiastowe. Przykłady: stara wersja WordPressa z known exploits; brak TLS / SSL (szyfrowania połączenia) na głównej domenie. Napraw w tym tygodniu.
• ŚREDNIE — ułatwiłoby działanie atakującemu, który już ma przyczółek. Przykłady: brakujące nagłówki bezpieczeństwa, słabe flagi ciasteczek (cookie). Napraw w tym miesiącu.
• NISKIE — kwestia higieny. Przykłady: baner serwera ujawnia wersję oprogramowania. Napraw przy najbliższej okazji, gdy i tak tam zaglądasz.
• INFORMACJA / Obserwacja — nie problem, tylko coś, co zauważyliśmy (np. „używasz Cloudflare"). Przydatny kontekst, nie wymaga działania.

2. Pewność wyniku — jak pewni jesteśmy?

Pasywne skanery patrzą na twoją stronę z zewnątrz, tak jak odwiedzający. Nie zawsze mogą być w 100% pewne, że wykrycie jest prawdziwe. Pewność wyniku to liczba, zazwyczaj 0–100%, mówiąca o tym, jak pewne jest samo wykrycie — niezależnie od tego, jak poważny byłby problem.

Scanthra używa modelu dwuwymiarowego: każde wykrycie ma zarówno poziom zagrożenia, jak i pewność wyniku. Pokazujemy tylko wykrycia z pewnością ≥ 50%. Wszystko poniżej trafia do sekcji Obserwacje, gdzie piszemy „zauważyliśmy to, nie jesteśmy pewni, oto dlaczego" — zamiast bić na alarm bez podstaw.

Praktyczna kolejność czytania:

1. Poziom WYSOKIE lub KRYTYCZNE przy pewności ≥ 80% — zacznij tutaj.
2. Poziom ŚREDNIE przy pewności ≥ 80% — zaplanuj do naprawy.
3. WYSOKIE lub KRYTYCZNE przy pewności 50–80% — najpierw zweryfikuj, potem napraw.
4. Pozostałe — zbierz w okno konserwacyjne.

3. Sposób naprawy — jeden akapit, po ludzku

Każde porządne wykrycie zawiera krótki akapit „jak naprawić", na którym deweloper może działać. W raportach Scanthra znajdziesz to w sekcji Napraw samodzielnie: zazwyczaj jedno lub dwa zdania, czasem gotowy do wklejenia fragment konfiguracji. Jeśli nie zarządzasz stroną sam(-a), to właśnie ta część do przesłania swojemu deweloperowi, agencji lub wsparciu hostingu.

Nie musisz rozumieć naprawy. Wystarczy, że możesz ją przekazać i zapytać: „czy możesz to zrobić i kiedy?"

4. Tagi zgodności — kto poza tobą się tym interesuje?

Wykrycia często noszą tagi takie jak GDPR:Art32, NIS2:Art21, OWASP:A05. To skróty mówiące „to nie tylko nasza opinia; regulator/standard X oczekuje, że to obsłużysz". Trzy tagi, które zobaczysz najczęściej:

• RODO Art. 32 — ogólna klauzula UE dotycząca „odpowiednich środków technicznych i organizacyjnych". Trafia tu szyfrowanie transmisji (HTTPS) i konfiguracja odporna na naruszenia.
• NIS2 (dyrektywa UE o cyberbezpieczeństwie) Art. 21 — minimalne środki z dyrektywy NIS2: zarządzanie ryzykiem, obsługa podatności, bezpieczeństwo łańcucha dostaw, szyfrowanie, kontrola dostępu. Nawet jeśli sam(-a) nie jesteś podmiotem regulowanym, duzi klienci będą coraz częściej o to pytać.
• OWASP (standard bezpieczeństwa aplikacji) Top 10 — lista branżowa najczęstszych zagrożeń dla aplikacji webowych. A05 to błędna konfiguracja, A07 to problemy z identyfikacją i uwierzytelnianiem itd.

A co z fałszywymi alarmami?

Żaden pasywny skaner nie jest doskonały. Czasem narzędzie oznaczy coś, co w twoim konkretnym środowisku nie jest problemem. Przykłady:

• „Brakujący nagłówek bezpieczeństwa", który jest ustawiony przez twoją sieć CDN wyżej w hierarchii i skaner tego nie widział.
• Ostrzeżenie „wersja CMS (systemu zarządzania treścią) jest przestarzała", gdy ciąg wersji jest celowo zmieniony przez wtyczkę do utwardzania.
• „Subdomena nie wskazuje nigdzie", gdy subdomena jest celowo zarezerwowana pod nadchodzące uruchomienie.

W razie wątpliwości: napraw i tak. Niemal każdy „fałszywy alarm" jest tani do wyeliminowania, a przy okazji usuwa szum z następnego skanu. Wyjątki to przypadki, gdy naprawa wymagałaby poważnej pracy — tam poproś dewelopera o potwierdzenie, zanim poświęcisz kilka godzin.

Jak przekazać raport deweloperowi

Jeśli przekazujesz PDF, trzy zdania wystarczą:

„Hej — zrobiliśmy skan bezpieczeństwa. Czy możesz spojrzeć na wykrycia o poziomie WYSOKIM i KRYTYCZNYM od strony 4 i powiedzieć mi, które możesz naprawić w tym sprincie, a które wymagają szerszego planowania? Chętnie zepchnę wszystko o poziomie NISKIM na później."

To wszystko. Deweloper nie potrzebuje tłumaczenia raportu — potrzebuje pozwolenia na priorytetyzację.

Jak wygląda „czysty" raport

Ostrzeżenie: nikt nie dostaje zera wykryć przy pierwszym skanie. Typowa strona małej firmy na WordPressie ląduje na ~8–15 wykryciach, głównie nagłówkach ŚREDNICH i higienie ciasteczek. Rozsądny cel dla „czystości" to:

• Zero KRYTYCZNYCH.
• Zero WYSOKICH starszych niż 30 dni.
• Ogólna ocena B lub lepsza na stronie tytułowej.

Cokolwiek ponad to to perfekcjonizm — przydatny, ale nie to, co dzieli cię od twoich klientów.

Jak Scanthra pisze swoje raporty

Celowo używamy prostego języka. Każde wykrycie ma wiersz wpływu na biznes („jeśli zostałoby wykorzystane, atakujący mógłby odczytać e-maile klientów, co byłoby naruszeniem RODO"), akapit napraw samodzielnie i mapę zgodności na początku — żebyś od razu widział(-a), którzy regulatorzy zwracają na to uwagę. Jeśli wykrycie jest graniczne, przenosimy je do Obserwacji, zamiast cię straszyć. Celem jest raport, który możesz przeczytać w pociągu w drodze do domu i zadziałać następnego ranka — nie 60-stronicowy PDF, który chowasz w folderze „straszne, zajmę się potem".