Monitoring dostępności mówi tylko, że strona główna odpowiada. W sklepie trzeba pilnować jeszcze pięciu rzeczy: kasy z produktem w koszyku, zmian w plikach, kont z uprawnieniami administratora, wolnego miejsca na dysku i tego, czy alert w ogóle do kogoś dochodzi. Opisujemy, jak sprawdzamy każdą z nich w sklepach WooCommerce i PrestaShop, którymi się opiekujemy, jak często, i co te kontrole wyłapały. Przykłady są anonimowe.
Dlaczego monitoring dostępności nie wystarcza w sklepie internetowym?
Typowy monitoring co kilka minut pobiera stronę główną i sprawdza kod odpowiedzi. Gdy dostaje 200, uznaje, że wszystko działa. Sklep za Cloudflare potrafi jednak oddawać stronę główną z cache długo po tym, jak serwer przestał działać.
Tak było na serwerze, na którym skończyło się miejsce na dysku. Koszyk, panel i API zwracały błąd 521, wszystkie strony na tym serwerze leżały, a strona główna sklepu dalej odpowiadała 200 z cache. Monitoring patrzący tylko na nią nie zgłosiłby niczego. Klient, który chciał zapłacić, widział błąd.
Uptime trzeba więc mierzyć na ścieżkach dynamicznych, takich jak koszyk, kasa czy formularz kontaktowy. Strona główna niewiele tu mówi, bo cache trzyma ją najdłużej, a i tak taki pomiar sprawdza tylko, czy strona odpowiada, a nie co na niej jest.
Chcesz, żeby ktoś pilnował Twojego sklepu? Aktualizujemy WordPressa, WooCommerce i PrestaShop na kopii i ustawiamy monitoring kasy, plików, kont, dysku i alertów. Opisz sklep, a powiemy, od czego zacząć. Opieka nad WordPress i PrestaShop →
Jak sprawdzić, czy kasa działa i nie ładuje obcego skryptu?
Skimmer kart wstrzyknięty w stronę kasy nie spowalnia sklepu i nie zmienia kodu odpowiedzi. Żeby go zobaczyć, trzeba obejrzeć kasę tak jak klient. Nasz skrypt robi to w czterech krokach:
- Dodaje produkt do koszyka przez Store API WooCommerce.
- Pobiera stronę kasy z tym koszykiem.
- Szuka znanych znaczników skimmerów w treści strony.
- Sprawdza nagłówek Content-Security-Policy i listę domen, z których ładują się skrypty.
Pierwszy krok jest konieczny. Pusta kasa w WooCommerce odpowiada przekierowaniem 302 do koszyka, więc kontrola bez produktu oglądałaby inną stronę i skimmera w treści kasy by nie zobaczyła. Listę domen porównujemy z tym, co sklep powinien ładować: bramka płatności, dostawa, analityka i baner cookies. Nowa domena na kasie to sygnał do sprawdzenia od razu. Szerzej o samym szukaniu skimmerów piszemy w poradniku jak sprawdzić, czy checkout nie kradnie kart.
Jak monitorować zmiany w plikach WordPressa i PrestaShop?
Monitoring integralności plików (FIM) zapisuje sumę kontrolną każdego pliku, gdy sklep jest czysty, a potem regularnie porównuje stan bieżący z tym zapisem. Każdy plik nowy, zmieniony albo usunięty trafia do raportu.
Liczymy sumy treści, a nie daty modyfikacji. Atakujący potrafią ustawić plikowi dowolną datę i w jednym incydencie złośliwy plik miał datę z 2019 r., choć powstał w 2025 r. Suma MD5 zmienia się przy każdej zmianie treści, niezależnie od daty.
Trzy wdrożenia, które prowadzimy:
- Serwer ze sklepem i kilkoma stronami: ok. 127 tys. plików w 4 katalogach, kontrola co godzinę z crona.
- Sklep WooCommerce na hostingu współdzielonym po włamaniu: monitor napisany w PHP, uruchamiany z crona hostingu co 30 minut, stan odniesienia 42 814 plików.
- Sklep WooCommerce w Dockerze: kontrola co 10 minut, która obok plików sprawdza rdzeń WordPressa, nowe katalogi wtyczek, pliki PHP poza wtyczkami i motywem, konta oraz bazę.
Na pierwszym z tych serwerów monitoring wykrył dropper, czyli plik, który pobiera i zapisuje kolejne złośliwe pliki. Siedział na sąsiedniej stronie, nie w sklepie. Strony na jednym serwerze dzielą zasoby, więc raport zmian czytamy w całości, łącznie z wpisami spoza sklepu.
Jak odróżnić aktualizację od włamania?
Po aktualizacji WordPressa raport FIM pokazuje dziesiątki zmienionych plików i bez dodatkowej kontroli łatwo je zatwierdzić hurtem razem z czymś obcym. Rozwiązaniem są oficjalne sumy kontrolne. Polecenia wp core verify-checksums i wp plugin verify-checksums porównują pliki z sumami publikowanymi przez wordpress.org. Zmiana zgodna z nimi to aktualizacja, każda inna idzie do sprawdzenia.
Wtyczki premium nie mają sum na wordpress.org. W audycie sklepu WooCommerce z 1 października 2026 r. 42 wtyczki z wordpress.org zgadzały się z sumami, a 35 płatnych sprawdziliśmy przeszukaniem sygnatur złośliwego kodu. Dla takich wtyczek zostaje też porównanie z własnym stanem odniesienia.
Same sumy też trzeba sprawdzić. W jednym sklepie WooCommerce WP-CLI miało w konfiguracji ścieżkę do innej kopii WordPressa niż ta, na której działał sklep. Aktualizacje i weryfikacja sum trafiały więc w nie ten katalog i raportowały, że wszystko jest w porządku. Wyszło to dopiero w niezależnej kontroli rdzenia, która pokazała 1232 nieaktualne pliki.
W PrestaShop pliki rdzenia i modułów porównujemy z oficjalnym wydaniem tej samej wersji, bo tylko tak widać kod dopisany do modułu, który na co dzień działa poprawnie.
Jak wykryć nowego administratora w WooCommerce?
Lista użytkowników z rolą „Administrator” nie pokazuje wszystkich, którzy mogą zarządzać sklepem. Spotkaliśmy konta z rolą klienta, którym nadano uprawnienia administratora bezpośrednio, z pominięciem roli. W panelu wyglądały jak zwykli kupujący.
Dlatego kontrola liczy konta po uprawnieniach, takich jak manage_options, install_plugins czy edit_users, i po poziomie użytkownika, a nie po nazwie roli. Bazę odpytujemy bezpośrednio SQL-em, bez ładowania WordPressa, bo zainfekowana wtyczka uruchamiana przy każdym żądaniu mogłaby inaczej podmienić wynik. Alert przychodzi tylko na konta, których nie było w stanie odniesienia. Więcej w artykule o ukrytych administratorach z rolą klienta.
Dlaczego pełny dysk wyłącza sklep?
Pełny dysk to awaria, której nie widać aż do chwili, gdy sklep przestaje działać. W jednym sklepie WooCommerce zdarzyła się cztery razy, za każdym razem przez coś, co rosło bez limitu:
- log integratora z systemem ERP urósł do 5,5 GB i Redis przestał zapisywać dane;
- wtyczka kopii zapasowych pocięła katalog uploads na 129 plików po ok. 400 MB, zajęła cały dysk i wszystkie strony na serwerze zwracały błąd 521;
- nieudana kopia zostawiła 49,5 GB plików tymczasowych;
- zapełnił się katalog plików tymczasowych w pamięci.
Po tych awariach działa tam kontrola co 15 minut z progiem 20 GB wolnego miejsca, a logi mają rotację. Kopia zapasowa zapisywana na tym samym dysku co sklep sama staje się przyczyną awarii, więc jej pliki tymczasowe też mają limit.
Skąd wiadomo, że alert w ogóle dotrze?
Spotkaliśmy alert, który przez 5 tygodni nie wyszedł z serwera. Wysyłała go lokalna poczta serwera, która nie dostarczała wiadomości na zewnątrz, więc monitoring działał i wykrywał zmiany, tylko nikt się o tym nie dowiadywał.
Od tamtej pory stosujemy trzy zasady. Alert idzie przez zewnętrzny serwer pocztowy, a przy uruchomieniu wysyłamy wiadomość próbną. Monitoring bez potwierdzonego dostarczenia uznajemy za niedziałający. Pierwszy alert przychodzi od razu, a jeśli problem nie zniknął, przypomnienie wraca co 6 godzin.
Jak rozpoznać scraper cen w ruchu sklepu?
W branżach, w których konkuruje się ceną, część ruchu to boty konkurencji, które co kilka godzin pobierają karty produktów. W logach jednego sklepu wyglądało to tak: serwer w centrum danych bez odwrotnego DNS, trzy własne nazwy User-Agent udające narzędzia do badań katalogu, ok. 1300 żądań, tylko HTML bez CSS i obrazków, ok. 20 pobrań każdej z 41 kart produktów na dobę, w nocy tyle samo co w dzień.
Takie boty blokujemy regułą WAF w Cloudflare po User-Agencie, z kodem 403. Po każdej regule sprawdzamy, czy Googlebot, bingbot i zwykła przeglądarka dalej dostają 200, bo źle napisana reguła potrafi odciąć sklep od Google i Merchant Center. Cały proces opisujemy w artykule jak zablokować scraper cen bez utraty Google.
Co i jak często sprawdzać w sklepie?
Poniżej zestawienie z naszych wdrożeń. Częstotliwość zależy od serwera, a na hostingu współdzielonym ogranicza ją cron hostingu.
| Co sprawdzamy | Jak często | Co wyłapuje |
|---|---|---|
| Kasa z produktem w koszyku | raz dziennie i po zmianach na kasie | skimmer w treści kasy, nowe domeny skryptów, brak CSP |
| Sygnatury, rdzeń, wtyczki, konta, JS w bazie | co 10 minut | webshelle, fałszywe wtyczki, nowych administratorów |
| Sumy plików (FIM) | co 30 minut do co godzinę | każdy nowy, zmieniony albo usunięty plik |
| Administratorzy, PHP w uploads, drop-iny, crontab | co godzinę | nowe konta i pliki w miejscach, gdzie PHP nie powinno być |
| Sumy rdzenia, sygnatury w plikach z ostatniej doby | raz dziennie | zmiany w rdzeniu i kod dopisany do istniejących plików |
| Ruch botów w logach Cloudflare i dostęp wyszukiwarek po zmianie reguł WAF | przy podejrzeniu scrapingu i po każdej zmianie reguł | scrapery cen, skanery, reguły odcinające Googlebota |
| Wolne miejsce na dysku | co 15 minut | rosnące logi i pliki kopii zapasowych |
Wszystkie te kontrole tylko wykrywają i alarmują. Żadna niczego nie kasuje, bo usunięty plik nie powie już, kiedy i skąd się pojawił. Jeśli monitoring wykrył włamanie, następnym krokiem jest usuwanie malware, a stałą opiekę z aktualizacjami na kopii i monitoringiem opisujemy na stronie opieka nad WordPress, WooCommerce i PrestaShop.
Dokumentacja: wp core verify-checksums i wp plugin verify-checksums (developer.wordpress.org).
