Przejdź do treści
Breachroad
Wróć do bloga
Narzędzia

Jak czytać wynik skanu bezpieczeństwa i naprawić problemy

Przeskanowałeś stronę i widzisz ocenę oraz listę problemów — co dalej? Tłumaczymy każdy typ znaleziska i pokazujemy, jak konkretnie go naprawić.

KR
Karol Rapacz
4 lipca 2026 · 11 min czytania
Jak czytać wynik skanu bezpieczeństwa i naprawić problemy

Przeskanowałeś swoją stronę naszym skanerem, zobaczyłeś ocenę „C”, poziom ryzyka „średnie” i listę kilkunastu problemów — i co teraz? Sam wynik to dopiero połowa historii; wartość pojawia się, gdy przełożysz go na konkretne poprawki. Ten poradnik prowadzi przez raport krok po kroku: co oznacza wynik, jak priorytetyzować i jak naprawić każdy typ znaleziska. Większość poprawek to zmiany w konfiguracji serwera lub DNS — do wykonania w kilka–kilkanaście minut.

Najpierw zrozum wynik, ocenę i ryzyko

Skaner wystawia trzy powiązane wartości:

  • Wynik (0–100) — startuje od 100 i maleje za brakujące zabezpieczenia. To ogólny wskaźnik higieny.
  • Ocena (A–F) — litera będąca skrótem wyniku, wygodna do szybkiego porównania.
  • Poziom ryzyka (niskie/średnie/wysokie) — orientacyjna waga problemów.

Kluczowa zasada: priorytetyzuj według ważności znaleziska, nie według kolejności na liście. Skaner sortuje problemy od najpoważniejszych — zacznij od góry. Znaleziska „krytyczne” i „wysokie” naprawiaj najpierw, „niskie” i „informacyjne” mogą poczekać.

Naprawianie problemów, typ po typie

Brak HTTPS lub przekierowania na HTTPS

To najpoważniejszy problem. Jeśli strona nie wymusza szyfrowanego połączenia, dane użytkowników są narażone w tranzycie. Napraw: zainstaluj certyfikat TLS (darmowy Let’s Encrypt) i skonfiguruj przekierowanie całego ruchu z HTTP na HTTPS (301). To fundament — bez niego reszta ma mniejsze znaczenie.

Brakujące nagłówki bezpieczeństwa

Najczęstsza kategoria znalezisk. Każdy nagłówek dodajesz w konfiguracji serwera (nginx/Apache) lub na poziomie aplikacji/CDN:

  • Content-Security-Policy — ogranicza źródła skryptów; największa ochrona przed XSS, ale wymaga dopasowania do strony (zacznij od trybu raportowania).
  • Strict-Transport-Security (HSTS) — wymusza HTTPS w przeglądarce; ustaw min. 6 miesięcy z includeSubDomains.
  • X-Frame-Options: DENY (lub CSP frame-ancestors) — blokuje clickjacking.
  • X-Content-Type-Options: nosniff — blokuje zgadywanie typu treści.
  • Referrer-Policy — np. strict-origin-when-cross-origin.
  • Permissions-Policy — wyłącza nieużywane API przeglądarki (kamera, mikrofon).

Szerzej rozpisaliśmy nagłówki i ich znaczenie w kontekście OWASP Top 10.

Ciasteczka bez flag Secure / HttpOnly / SameSite

Jeśli skaner zgłasza cookie bez flag: Secure (wysyłane tylko po HTTPS), HttpOnly (niedostępne dla skryptów — chroni przed kradzieżą sesji przez XSS) i SameSite (ochrona przed CSRF). Ustaw je w konfiguracji aplikacji dla ciasteczek sesyjnych. To szybka i wartościowa poprawka.

Problemy z pocztą: brak SPF / DMARC

Jeśli skaner pokazuje brak SPF lub DMARC, Twoją domenę można łatwiej podrobić w e-mailach. Napraw: dodaj rekord SPF wskazujący dozwolone serwery, włącz DKIM u dostawcy poczty i wdróż DMARC — zaczynając od p=none (monitorowanie), a docelowo p=quarantine/p=reject. Cały proces opisaliśmy w poradniku SPF/DKIM/DMARC.

Ekspozycja wrażliwych plików (.git, .env)

To najgroźniejsze z „konfiguracyjnych” znalezisk. Publicznie dostępny katalog .git albo plik .env może ujawnić kod źródłowy, hasła i klucze. Napraw natychmiast: zablokuj dostęp do tych ścieżek w konfiguracji serwera, a jeśli sekrety były wystawione — zrotuj je (zmień hasła, klucze API), bo mogły już zostać wykradzione.

Podatności bibliotek (przestarzałe wersje JS)

Skaner wykrył starą wersję biblioteki (np. jQuery, Lodash) ze znanymi CVE. Napraw: zaktualizuj bibliotekę do najnowszej wersji. To ten sam mechanizm, co w szerszym zarządzaniu podatnościami — przestarzałe komponenty to jedna z najczęstszych dróg ataku.

Ekspozycja serwera i adresów e-mail

Nagłówki Server i X-Powered-By ujawniające wersję ułatwiają atakującemu dobór exploita — ukryj wersję w konfiguracji. Wykryte adresy e-mail w treści bywają zbierane przez boty (spam, phishing) — rozważ formularze kontaktowe zamiast adresów wprost. To znaleziska o niższej wadze, ale warto je domknąć.

Po naprawie: przeskanuj ponownie

Po wdrożeniu poprawek uruchom skan jeszcze raz i porównaj wynik. Skaner jest bezstanowy, więc nie przechowuje historii — jeśli chcesz śledzić postęp, pobierz raport JSON przed i po zmianach. Rosnący wynik i znikające znaleziska to najlepszy dowód, że poprawki zadziałały.

Kiedy skan to za mało

Skaner pasywny zamyka konfigurację widoczną z zewnątrz, ale są rzeczy, których nie znajdzie: błędy logiki biznesowej, luki w kontroli dostępu (użytkownik widzi cudze dane), podatności typu SQL injection czy XSS wymagające aktywnego testowania. Jeśli Twoja strona przetwarza dane klientów, obsługuje płatności albo logowanie użytkowników, warto uzupełnić skan o manualny test penetracyjny — to on znajduje luki, które automat pomija.

Najczęstsze pytania (FAQ)

Mam wynik „C” — czy to źle? Niekoniecznie tragicznie, ale jest co poprawić. „C” zwykle oznacza działający HTTPS, ale braki w nagłówkach lub ciasteczkach. Dobra wiadomość: to najczęściej najtańsze poprawki (kilka linii w konfiguracji), które szybko podnoszą wynik i realną odporność.

Od czego zacząć, jeśli problemów jest dużo? Od góry listy, czyli od najpoważniejszych: najpierw HTTPS i przekierowanie, potem CSP i pozostałe nagłówki, ekspozycja wrażliwych plików (jeśli wykryta — to priorytet), a na końcu drobiazgi jak ekspozycja wersji serwera. Skaner już posortował znaleziska według wagi.

Naprawiłem wszystko, a wynik nie jest 100 — dlaczego? Część znalezisk jest informacyjna (np. brak security.txt, wykryte technologie) i nie zawsze da się je „naprawić” ani nie zawsze warto. Nie chodzi o sztuczne 100/100, lecz o zamknięcie realnych braków. Wynik w okolicach A z domkniętymi problemami wysokiej i średniej wagi to bardzo dobry rezultat dla skanu pasywnego.

Czy poprawki wymagają programisty? Większość (nagłówki, cookies, SPF/DMARC, blokada ścieżek) to zmiany w konfiguracji serwera lub DNS — poradzi sobie administrator lub osoba obsługująca hosting. Bardziej złożone (dopasowanie CSP, aktualizacja bibliotek w aplikacji) mogą wymagać dewelopera.

Chcę mieć pewność, że nic nie przeoczyłem — pomożecie? Tak. Po samodzielnym domknięciu braków warto zweryfikować całość niezależnie. Audyt lub test penetracyjny sprawdza to, czego skan pasywny nie obejmuje. Umów bezpłatną konsultację, a pomożemy dobrać zakres do Twojej strony.

Podsumowanie

Wynik skanu jest wartościowy dopiero wtedy, gdy zamienisz go w poprawki. Zacznij od najpoważniejszych znalezisk (HTTPS, ekspozycja plików, CSP), naprawiaj kolejno według wagi, a po zmianach przeskanuj ponownie, by potwierdzić efekt. Większość braków domkniesz w konfiguracji w kilkanaście minut. A gdy chcesz mieć pewność, że nie zostało nic ukrytego pod powierzchnią — uzupełnij skan o manualny test. Przeskanuj swoją stronę i zabierz się za listę.


Skaner działa pasywnie i bezstanowo. Pełny obraz ryzyka daje manualny test penetracyjny. Porozmawiajmy.

Udostępnij artykuł

Usługi Umów konsultację