Audyt bezpieczeństwa strony

Zewnętrzna kontrola tego, jak strona chroni odwiedzających: HTTPS i certyfikat, nagłówki bezpieczeństwa, ciasteczka, mieszana treść, CORS i pliki, których wdrożenie nie powinno publikować.

• Wszystkie usługi

Audyt bezpieczeństwa odpowiada na jedno praktyczne pytanie: co widzi atakujący, patrząc na Twoją stronę z zewnątrz, i które drzwi zostały otwarte, choć ich zamknięcie nie kosztuje prawie nic? SiteScan.top patrzy na stronę dokładnie tak, jak widzi ją każdy odwiedzający lub bot — bez dostępu do serwera, bez instalowania agentów i bez zmian w kodzie — i zamienia znaleziska w listę konkretnych poprawek z priorytetem przy każdej.

Co obejmuje audyt

HTTPS i certyfikat. Sprawdzamy, czy strona odpowiada przez HTTPS i przekierowuje tam zwykły HTTP, czy certyfikat jest ważny, wystawiony na właściwą nazwę i nie wygasa w najbliższych tygodniach, czy łańcuch jest kompletny, a podpis nowoczesny. Pokazujemy, które wersje TLS serwer wciąż akceptuje: TLS 1.0 i 1.1 zostały wycofane, a serwer, który je obsługuje, nie przechodzi kontroli zgodności i zostawia miejsce na ataki obniżenia protokołu.

Nagłówki bezpieczeństwa. Nagłówki odpowiedzi decydują, na ile przeglądarka może ufać stronie. Audyt czyta wszystkie istotne:

• Strict-Transport-Security — czy HSTS jest włączony, jak długo przeglądarka go pamięta, czy obejmuje subdomeny i czy domena kwalifikuje się do listy preload przeglądarek;
• Content-Security-Policy — czy polityka w ogóle istnieje i czy naprawdę ogranicza skrypty, czy też dopuszcza unsafe-inline i dowolne hosty;
• X-Frame-Options i frame-ancestors — ochrona przed clickjackingiem, gdy Twoja strona zostaje niewidocznie osadzona w cudzej;
• X-Content-Type-Options, Referrer-Policy, Permissions-Policy — małe nagłówki, które jedną linijką konfiguracji zamykają całe klasy problemów.

Mieszana treść i ciasteczka. Strona serwowana przez HTTPS, która ładuje skrypt lub obraz przez HTTP, jest bezpieczna tylko w takim stopniu jak jej najsłabszy zasób. Skanowanie pokazuje każdy taki zasób na każdej odwiedzonej stronie. Ciasteczka są sprawdzane pod kątem flag Secure, HttpOnly i SameSite: bez nich ciasteczko sesji może trafić do nieszyfrowanego połączenia albo zostać odczytane przez skrypt wstrzyknięty do strony.

CORS i niebezpieczne metody. Wysyłamy żądanie z obcego źródła i patrzymy na odpowiedź. Serwer, który odsyła dowolny Origin i zezwala na dane uwierzytelniające, pozwala każdej stronie otwartej przez zalogowanego użytkownika czytać Twoją witrynę w jego imieniu. Sprawdzamy też, czy serwer odpowiada na TRACE — metodę, której nie potrzebuje żadna strona.

Odsłonięte pliki. Wdrożenie czasem publikuje to, czego nie powinno nigdy: .env z hasłami do bazy, katalog .git z całą historią kodu, zrzuty SQL i archiwa, listingi katalogów, mapy źródeł JavaScript. Każde znalezisko jest potwierdzane treścią odpowiedzi, a nie tylko kodem statusu, więc strona „200 OK” z napisem „nie znaleziono” nie trafi do raportu jako wyciek.

Konwencje bezpieczeństwa. Plik /.well-known/security.txt mówi badaczom, gdzie zgłaszać podatności; adres change-password pozwala menedżerom haseł skierować użytkownika prosto do właściwego formularza. Żadne z nich nie jest obowiązkowe, ale oba świadczą o dojrzałej stronie.

Jak to działa

Wpisujesz adres strony i uruchamiasz skanowanie. Skaner otwiera strony w prawdziwej przeglądarce, przechodzi po linkach wewnętrznych i wykonuje testy serwera. Każde żądanie jest zwykłym żądaniem, które mógłby wysłać odwiedzający: audyt nie zgaduje haseł, nie wysyła exploitów i nie obciąża strony. Typowe skanowanie trwa minutę lub dwie.

Co otrzymujesz

Wynikiem jest raport z ogólną oceną bezpieczeństwa i listą znalezisk posortowanych według wagi. Każde znalezisko mówi, co wykryto, pod jakim adresem, dlaczego to ważne i jak to naprawić — zwykle z gotową linijką konfiguracji dla nginx, Apache lub aplikacji. Znaleziska, które są kwestią wyboru, a nie błędem (DNSSEC, CAA, HSTS preload), są oznaczone jako opcjonalne, by nie przesłaniały ważnych.

Raportem można się podzielić linkiem, wyeksportować go do PDF dla klienta lub wykonawcy albo skopiować jako gotowe zadanie dla programisty. Dodaj stronę do monitoringu, a audyt będzie powtarzany według harmonogramu: jeśli wydanie usunie nagłówek albo certyfikat zbliży się do końca ważności, dostaniesz e-mail lub wiadomość w Telegramie, zamiast dowiedzieć się o tym od użytkowników.

Dla kogo

Audyt przydaje się przed uruchomieniem nowej strony, po przeprowadzce do innego hostingu lub CDN, przed testem penetracyjnym (by pentesterzy wydali budżet na prawdziwe problemy, a nie na brakujące nagłówki) oraz jako regularna kontrola dla agencji utrzymujących dziesiątki stron klientów. Nie zastępuje pełnego testu penetracyjnego, ale w kilka minut i za ułamek kosztów wyłapuje najczęstsze błędy konfiguracji.