Bezpieczeństwo strony to nie dodatek — to podstawa

Wyobraźcie sobie sklep, który zamyka drzwi na noc, ale nigdy nie sprawdza, czy okno na zapleczu w ogóle się domyka. Nikt złośliwy go nie obserwuje — po prostu ktoś, kiedyś, sprawdzi tę klamkę, bo sprawdza wszystkie klamki w mieście, po kolei, automatycznie. Dokładnie tak działa internet wobec małych stron firmowych. Problem nie zaczyna się od tego, że ktoś Was wybrał. Zaczyna się od tego, że nikt nie sprawdził, czy okno się domyka.

Dlaczego mała firma czuje się bezpieczna — i dlaczego to złudzenie

Właściciele małych firm traktują bezpieczeństwo strony jak alarm w mieszkaniu na parterze w spokojnej okolicy — coś, co "może kiedyś" warto dokupić, jeśli zostanie budżet. To rozumowanie brzmi racjonalnie, dopóki nie zapytamy, skąd właściwie bierze się to poczucie spokoju. Odpowiedź jest mniej pochlebna, niż mogłoby się wydawać: to nie analiza ryzyka, tylko dobrze opisany błąd poznawczy.

W psychologii nazywa się to nierealistycznym optymizmem (ang. unrealistic optimism) — tendencją do oceniania własnego ryzyka jako niższego niż ryzyko innych, w identycznej sytuacji. Zjawisko opisał już w 1980 roku psycholog Neil Weinstein, pokazując na ośmiu różnych zagrożeniach — od wypadku samochodowego po chorobę serca — że badani systematycznie zaniżali prawdopodobieństwo tego, że coś złego przydarzy się im, w porównaniu z tym, jak oceniali szanse rówieśnika w tej samej sytuacji. Nie chodziło o brak wiedzy o statystykach. Chodziło o coś głębszego: mózg traktuje siebie jako wyjątek od reguły, którą świetnie rozumie w odniesieniu do innych.

Przełóżcie to na stronę internetową. Właściciel firmy doskonale wie, że wycieki danych się zdarzają — czytał o nich, może nawet komentował w rozmowie ze znajomym "no, teraz to trzeba uważać". A jednocześnie, patrząc na własną, skromną stronę wizytówkową, myśli: ale nie u mnie, nie ma tu niczego wartościowego. To zdanie zakłada coś, co jest po prostu nieprawdą — że atakujący najpierw oceniają wartość celu, a dopiero potem decydują się zaatakować.

Skala automatycznego ruchu, który nigdy nie śpi

Źródło: Imperva/Thales Bad Bot Report 2026.

Źródło: analiza SiteLock (7 mln witryn) + Imperva/Thales Bad Bot Report 2026.

Warto zatrzymać się na chwilę przy tej drugiej liczbie, bo łatwo przeczytać ją i pójść dalej, nie czując jej ciężaru. 94 próby dziennie oznacza próbę mniej więcej co piętnaście minut, przez całą dobę, siedem dni w tygodniu, bez wyjątku na weekendy czy święta. Nie ma tu "spokojnego okresu po uruchomieniu strony". Badania z użyciem honeypotów — serwerów-przynęt wystawionych celowo do obserwacji ruchu — konsekwentnie pokazują pierwsze automatyczne skany w ciągu kilkunastu minut do kilku godzin od podłączenia nowego adresu do sieci. Zanim strona trafi do Google. Zanim ktokolwiek o niej usłyszy. Zanim właściciel zdąży dodać ją do wizytówki Google Maps.

Skąd biorą się luki — i dlaczego to prawie zawsze wtyczki

Większość stron internetowych na świecie powstaje na systemach zarządzania treścią z rozbudowanym ekosystemem wtyczek — WordPress i jego liczne odmiany są tu zdecydowanym liderem. Wtyczki są wygodne. Instaluje się je jednym kliknięciem, obiecują funkcję, o której ktoś pomyślał pięć minut temu, i w większości przypadków po prostu działają. To właśnie ta wygoda jest źródłem problemu — nie dlatego, że wtyczki są źle napisane z założenia, ale dlatego, że każda dodana wtyczka to niezależny, obcy kawałek kodu, którego nikt z zespołu strony nie napisał i nie kontroluje w pełni.

Źródło: raporty branżowe firm zajmujących się bezpieczeństwem WordPressa (m.in. Patchstack, WPScan) — analizy podatności publikowanych w bazie CVE dla ekosystemu WordPress.

To liczba, która powinna odwracać całą powszechną intuicję na temat tego, co znaczy "bezpieczna strona". Rozmowa o bezpieczeństwie zwykle skupia się na haśle, na hostingu, na tym, czy jest certyfikat SSL. Tymczasem realne ryzyko w ogromnej większości przypadków nie leży w żadnym z tych miejsc — leży w liczbie zainstalowanych, często dawno zapomnianych wtyczek, które nikt regularnie nie aktualizuje, bo aktualizacja bywa ryzykowna (może coś zepsuć wizualnie) albo po prostu nikt o niej nie pamięta miesiącami. Im dłużej strona istnieje bez przeglądu, tym dłuższa staje się lista cichych, nieaktualizowanych zależności.

Konsekwencje, których większość firm nie liczy z góry

• Obowiązek zgłoszenia w 72 godziny. Jeśli w wycieku znalazły się dane osobowe — a formularz kontaktowy z imieniem, telefonem i e-mailem to dane osobowe — RODO wymaga zgłoszenia do Prezesa Urzędu Ochrony Danych Osobowych w ciągu 72 godzin od wykrycia. Brak zgłoszenia to osobne naruszenie, karane niezależnie od samego wycieku.
• Czarna lista Google. Zainfekowana strona prędzej czy później trafia do bazy Google Safe Browsing — a wtedy każdy odwiedzający widzi pełnoekranowe, czerwone ostrzeżenie zamiast oferty firmy. Usunięcie wpisu trwa dni, czasem tygodnie, i wymaga aktywnego zgłoszenia oczyszczenia strony.
• Spadek widoczności w wyszukiwarce. Zainfekowane strony są degradowane w wynikach wyszukiwania niezależnie od wcześniej wypracowanej pozycji — cały efekt pracy nad SEO zostaje zawieszony do czasu wyczyszczenia i ponownej weryfikacji.
• Koszt naprawy wielokrotnie wyższy niż koszt prewencji. Cykliczny raport IBM "Cost of a Data Breach" konsekwentnie pokazuje, że koszt reakcji na już zaistniały incydent — analiza, czyszczenie, powiadomienia, przestój — jest o rząd wielkości wyższy niż koszt wdrożonych z góry zabezpieczeń podstawowych.

Anatomia jednego automatycznego ataku

Warto rozłożyć to na czynniki pierwsze, bo słowo "atak" przywołuje w wyobraźni obraz człowieka przy klawiaturze, wpatrzonego w ekran, celowo wybierającego ofiarę. Rzeczywistość jest dużo bardziej biurokratyczna i dużo mniej dramatyczna. Cały proces przebiega w trzech krokach, z których każdy trwa ułamki sekundy na jedną stronę:

1. Rozpoznanie. Bot ustala, jaki system obsługuje stronę — jaka wersja, jaki serwer — na podstawie publicznie widocznych znaczników w kodzie i nagłówkach odpowiedzi serwera.
2. Skan podatności. Wysyła serię zapytań pod znane, powtarzalne ścieżki. W praktyce ok. jedna trzecia takich skanów szuka plików .env, kolejna jedna trzecia — folderu .git, czyli repozytorium z historią kodu, czasem z hasłami zapisanymi w środku.
3. Automatyczne wykorzystanie. Jeśli coś się znajdzie — luka, publicznie dostępny plik, słabe hasło — kod wykonuje się natychmiast, bez udziału człowieka po drugiej stronie, bez namysłu, bez wahania.

To, co dzieje się z przejętą stroną, rzadko ma coś wspólnego z jej właścicielem. Serwer zaczyna rozsyłać spam pod szyldem firmowej domeny. Powstaje ukryty podfolder z fałszywym formularzem logowania do banku, podczas gdy strona główna wygląda dokładnie tak jak zawsze. Maszyna dołącza do sieci zainfekowanych urządzeń atakujących wspólnie inny, dużo większy cel. Właściciel może tego wszystkiego nie zauważyć poza jednym sygnałem: firmowa poczta zaczyna nagle lądować w spamie u odbiorców.

Jak podchodzimy do tego inaczej

Zamiast dokładać zabezpieczenia na końcu, jako "opcję do dokupienia", eliminujemy największe źródło ryzyka już na etapie decyzji o architekturze strony — zanim padnie pierwsza linijka kodu.

• Zero wtyczek do aktualizowania. Piszemy własny kod zamiast składać stronę z gotowych, cudzych komponentów. Nie ma tu warstwy, której nie rozumiemy i nie kontrolujemy — a więc nie ma tej samej powierzchni ataku, którą mają strony złożone z dziesiątek wtyczek.
• Mniej kodu, mniej miejsc na błędy. Strona ważąca dziesiątki kilobajtów i wykonująca kilka zapytań HTTP ma po prostu mniej miejsc, w których może się coś ukryć, w porównaniu ze stroną złożoną z megabajtów cudzego kodu.
• Audyt bezpieczeństwa jako standardowy krok, nie usługa dodatkowa. Każdy projekt przechodzi sprawdzenie pod kątem najczęściej wykorzystywanych, znanych ścieżek ataku — zanim trafi do sieci, nie po pierwszym incydencie.
• Zostajemy po starcie. Strona bez wtyczek nie eliminuje potrzeby opieki całkowicie, ale skraca listę rzeczy, które trzeba pilnować, z dziesiątek do kilku — a te kilka rzeczy faktycznie pilnujemy.

W skrócie

Pytanie nigdy nie brzmiało "czy nasza strona jest wystarczająco interesująca, żeby ktoś chciał ją zaatakować". Brzmiało: "czy nasza strona jest wystarczająco niezabezpieczona, żeby automatyczny skaner, który i tak sprawdza wszystkie strony po kolei, znalazł w niej coś do wykorzystania". To druga wersja pytania, mniej pochlebna dla naszego poczucia bezpieczeństwa, ale dużo bliższa temu, jak rzeczywiście wygląda ruch w internecie.

Efekty tej pracy nie znikają w raportach wysyłanych raz na kwartał — nasi klienci widzą wynik bezpieczeństwa i całodobowy monitoring swojej strony na bieżąco w panelu klienta.