Kod HTTP 200 mówi tylko, że serwer odpowiedział. Nie mówi nic o tym, czy strona rzeczywiście działa – baza może akurat leżeć, treść się nie załadować, a monitoring patrzący wyłącznie na kod odpowiedzi niczego z tego nie zauważy.
Z tego założenia Piotr zbudował Strażnika Witryn – zgłoszenie na konkurs StormIT z okazji Dnia Programisty. Całość stoi w n8n i pilnuje jednocześnie czterech różnych rzeczy: dostępności, poprawności działania, integralności treści oraz wybranych aspektów bezpieczeństwa.
„Jest to automatyzacja przygotowana w n8n, której zadaniem jest monitorowanie stron internetowych nie tylko pod kątem dostępności, ale również poprawności działania, integralności treści oraz wybranych aspektów bezpieczeństwa.”
Co dokładnie wykrywa
- ciche awarie mimo odpowiedzi HTTP 200,
- brak kluczowych elementów strony,
- znane zagrożenia zadeklarowanych zależności przez OSV API,
- zmianę treści HTML na podstawie hasza SHA-256,
- sygnatury charakterystyczne dla prób prompt injection – bez użycia modelu AI, samymi regułami,
- a także wykonanie samego Strażnika, przez Healthchecks.io.
Jak to działa w n8n
Główny workflow, „Guardian Website Monitor”, startuje codziennie o 7:00. Po sygnale startowym do Healthchecks.io i wczytaniu konfiguracji z Google Sheets (arkusze Sites, Checks, Dependencies, Results, Runs) system buduje kontekst i wybiera aktywne witryny do sprawdzenia.
Pobranie strony i podstawowe kontrole
HTTP-001, MIME-001, TITLE-001, CTA-001, EMAIL-001 – zestaw kontroli sprawdzających, czy strona nie tylko odpowiada, ale ma na miejscu to, co powinna mieć.
Hash SHA-256 i porównanie z poprzednim
Treść HTML trafia przez funkcję kryptograficzną, a wynik porównywany jest z ostatnim zapisanym haszem – wykryta zmiana to CHANGE-001.
Skan bezpieczeństwa, jeśli potrzebny
Przy pierwszym uruchomieniu (baseline) albo po wykryciu zmiany treści system uruchamia Guardrails – dopasowanie słów kluczowych i własnych wyrażeń regularnych, bez udziału modelu AI – i ocenia wynik jako GUARD-001.
Kontrola zależności równolegle
Osobna gałąź odczytuje aktywne zależności witryny, odpytuje OSV API o znane podatności i zapisuje ocenę jako DEP-001.
Zapis i alert
Wyniki wszystkich kontroli trafiają do arkusza Results. Po sprawdzeniu wszystkich witryn system podsumowuje przebieg w arkuszu Runs i decyduje, czy wysłać mail z alertem – z tematem oznaczonym [FAIL], [CHANGE] albo [SECURITY] – czy zakończyć sygnałem sukcesu do Healthchecks.io.
Drugi workflow, „Guardian Demo Website”, to kontrolowane środowisko testowe uruchamiane przez webhook z parametrem trybu. Dzięki niemu Piotr może przełączać testową witrynę między czterema stanami – ok (pełna poprawna strona), silent_failure (HTTP 200, ale brak CTA), down (HTTP 503) i prompt_injection (HTTP 200 z ukrytą podejrzaną treścią) – i sprawdzać, czy Strażnik faktycznie rozpoznaje każdy z nich, bez konieczności psucia prawdziwej strony.
Wersja konkursowa, z planem na dalej
Piotr traktuje to zgłoszenie jako wstępną wersję.
„Jest to wstępna wersja na potrzeby konkursu. W bardziej rozbudowanej wersji dodałbym jeszcze sprawdzanie certyfikatu SSL oraz jego ważności i wysyłanie powiadomień, gdy jego ważność będzie się kończyła.”
Do zgłoszenia dołączył komplet materiałów: opis rozwiązania w PDF, prezentację w PowerPoincie, pliki JSON z automatyzacjami gotowe do zaimportowania w n8n, ilustrację ze schematem całego przepływu, zrzut z Healthchecks.io oraz arkusz z konfiguracją. To poziom dokumentacji, jakiego można oczekiwać po kimś, kto myśli o swoim projekcie nie jako o jednorazowym demo, tylko jako o rozwiązaniu, które ktoś inny mógłby odtworzyć.
To kolejny z projektów, jakie kursanci StormIT budują w trakcie nauki. Zobacz pozostałe albo sprawdź, jak zacząć swój.