Oznaki, że Twój sklep PrestaShop potrzebuje audytu bezpieczeństwa (i jak najpierw sprawdzić go samodzielnie)

Ostatnia aktualizacja: czerwiec 2026.

Większość sklepów PrestaShop nie potrzebuje kupować narzędzia bezpieczeństwa. Potrzebuje wiedzieć, na co faktycznie jest narażona — a większość właścicieli naprawdę tego nie wie, bo nic złego nie widać. Skimmer może działać na stronie finalizacji zakupu przez tygodnie, podczas gdy zamówienia spływają normalnie. Podatny moduł może pozostawać bez poprawki przez lata, zanim ktoś zacznie go skanować. Celem przeglądu bezpieczeństwa nie jest straszenie; chodzi o zastąpienie „chyba raczej wszystko jest w porządku” jasną odpowiedzią opartą na dowodach. Ten artykuł pokazuje konkretne sygnały, które wymagają bliższego przyjrzenia się sklepowi, i daje Ci test, który wykonasz samodzielnie w około dziesięć minut, zanim zdecydujesz, czy w ogóle potrzebujesz pomocy z zewnątrz.

Sygnały, które naprawdę mają znaczenie

To nie są teoretyczne problemy. Każdy z nich widzieliśmy już jako przyczynę realnego incydentu w prawdziwych sklepach. Traktuj je jak czynniki ryzyka — im więcej ich dotyczy Twojego sklepu, tym bardziej uporządkowany audyt jest wart Twojego czasu.

Działasz na starej lub niewspieranej wersji PrestaShop

PrestaShop 1.6 od dawna jest po zakończeniu cyklu życia, a większość gałęzi 1.7.x nie otrzymuje już poprawek bezpieczeństwa. Nawet w 8.x instalacja opóźniona o kilka wersji pomniejszych może nie mieć łatek na publicznie znane problemy. Stary rdzeń to najważniejszy pojedynczy wskaźnik narażenia, bo atakujący nie muszą znajdować nowej luki — po prostu skanują sklepy pod kątem tych już opisanych. Jeśli nie potrafisz podać dokładnej wersji bez sprawdzania, to samo w sobie jest sygnałem.

Twoje moduły nie były aktualizowane od lat

To jest prawdziwa powierzchnia ataku w większości sklepów. Rdzeń przyciąga uwagę; moduły firm trzecich po cichu się starzeją. Historia jest długa — SQL injection w blockwishlist, oparte na Smarty wstrzykiwanie szablonów po stronie serwera (SSTI) prowadzące do zdalnego wykonania kodu w kilku modułach oraz stały strumień mniej znanych luk. Moduł, który kiedyś zainstalowałeś i o nim zapomniałeś, jest idealnym punktem wejścia właśnie dlatego, że nikt go nie pilnuje. Jeśli lista aktualizacji modułów pokazuje stos zaległych aktualizacji albo moduły od dostawców, którzy już nie istnieją, potraktuj to jak czerwone światło.

Panel administracyjny jest pod domyślną ścieżką, bez ograniczania prób logowania lub 2FA

Panel administracyjny dostępny pod przewidywalnym URL-em, bez ochrony przed brute force i bez uwierzytelniania dwuskładnikowego, to otwarte zaproszenie dla botów próbujących logowania na podstawie wyciekłych danych i zgadywania haseł. Działają bez przerwy i nie muszą być sprytne — wystarczy im jedno słabe lub ponownie użyte hasło z konta pracownika.

Brak WAF, a adres IP serwera źródłowego jest ujawniony

Jeśli Twój sklep stoi bezpośrednio w otwartym internecie bez zapory aplikacji webowych, każde złośliwe żądanie trafia do kodu aplikacji bez filtrowania. Gorzej, jeśli używasz CDN, ale prawdziwy adres IP serwera źródłowego wycieka (w historii DNS, nagłówkach poczty albo starej subdomenie), atakujący mogą całkowicie ominąć ochronę i uderzyć prosto w serwer.

Niewyjaśnione pliki, zmodyfikowany rdzeń albo konta administratorów, których nie rozpoznajesz

Przypadkowe pliki PHP w katalogu głównym WWW, pliki rdzenia różniące się od czystego wydania albo wpis na liście pracowników, którego nikt z zespołu nie utworzył — każda z tych rzeczy może oznaczać, że sklep został już przejęty. Backdoory są projektowane tak, żeby wyglądały nudno i pozostawały cicho, więc rzadko same się ujawniają.

Finalizacja zakupu lub formularz płatności „wygląda trochę inaczej”

To jest sygnał, który kosztuje najwięcej. Skimmery w stylu Magecart wstrzykują kilka linii JavaScriptu, które po cichu kopiują dane kart podczas wpisywania ich przez klientów, a następnie wysyłają je na serwer atakującego. Strona nadal działa. Zamówienie nadal się kończy. Wycieka tylko numer karty. Jeśli finalizacja zakupu wygląda subtelnie inaczej — dodatkowe pole, przesunięty układ, skrypt, którego nie pamiętasz — potraktuj to poważnie. Dokładnie opisaliśmy, jak działa taki przypadek, w naszym tekście anatomia ataku Magecart na skimmer w PrestaShop.

Brak monitorowania integralności plików i brak kopii zapasowych poza serwerem

Jeśli nie masz sposobu, żeby wykryć zmianę pliku, nie odróżnisz czystego sklepu od przejętego — i zwykle dowiesz się o problemie od klienta albo operatora płatności. A jeśli jedyne kopie zapasowe znajdują się na tym samym serwerze (albo nigdy realnie nie przetestowałeś odtworzenia), przejęcie sklepu lub awaria dysku może zakończyć nie tylko dzień, ale cały biznes.

Przechowujesz więcej danych klientów, niż potrzebujesz

Każde dodatkowe pole, które zatrzymujesz, to odpowiedzialność, którą bierzesz na siebie. Przechowywanie pełnych danych kart, trzymanie wieloletnich danych osobowych bez polityki retencji albo logowanie wrażliwych szczegółów zmienia naruszenie z „wstydliwego” w problem PCI-DSS i RODO o realnej wadze finansowej i prawnej. Najbezpieczniejsze dane to te, których nigdy nie przechowywałeś.

10-minutowy test samodzielny

Zanim poprosisz kogokolwiek o pomoc — także nas — wykonaj go samodzielnie. Nic nie kosztuje, a mówi bardzo dużo:

• Potwierdź dokładną wersję PrestaShop i sprawdź, czy nadal jest wspierana. Jeśli to 1.6.x albo wczesne 1.7.x, już znasz odpowiedź.
• Otwórz listę aktualizacji modułów w panelu administracyjnym i policz oczekujące aktualizacje. Zwróć uwagę na moduły od dostawców, którzy zniknęli.
• Wypisz pracowników z dostępem administracyjnym. Sprawdź tabelę ps_employee albo stronę zespołu i zweryfikuj każde konto z dostępem do panelu administracyjnego.
• Porównaj pliki rdzenia z czystą kopią tej samej wersji PrestaShop. Każda modyfikacja w /classes, /controllers albo katalogu głównym, której nie wprowadzałeś, zasługuje na sprawdzenie.
• Posortuj katalog główny WWW według daty modyfikacji. Ostatnio zmienione pliki, których nie potrafisz wyjaśnić, to najszybszy sposób wykrycia backdoora.
• Potwierdź, że kopie zapasowe istnieją poza serwerem i naprawdę dają się odtworzyć. Kopia zapasowa, której nigdy nie testowałeś, to nadzieja, nie kopia zapasowa.

Jeśli wszystkie sześć punktów wychodzi czysto, to naprawdę uspokajający wynik — i być może nie musisz wydawać ani grosza. Jeśli którykolwiek z nich budzi niepokój, ten niepokój jest właśnie użytecznym sygnałem.

Jeśli masz dostęp do powłoki lub bazy danych, trzy polecenia tylko do odczytu

Potwierdzają kilka powyższych kontroli i są ściśle tylko do odczytu — wyświetlają i porównują, niczego nie zmieniają. Dostosuj prefiks tabel ps_ do własnego sklepu.

# 1. List every account with back-office access — look for anyone you don't recognise
SELECT id_employee, email, lastname, firstname, active, last_connection_date
FROM ps_employee
ORDER BY last_connection_date DESC;

# 2. Spot recently-modified PHP files in the webroot (a common backdoor tell)
find /path/to/your/shop -name '*.php' -mtime -30 -printf '%TY-%Tm-%Td  %p\n' \
  | sort

# 3. Confirm your stored PrestaShop version, then compare it to the supported list
mysql -e "SELECT value FROM ps_configuration WHERE name='PS_VERSION_DB';"

Zapytanie o pracowników to najszybszy sposób, żeby wyłapać obce konto administratora; nieznany adres e-mail albo wiersz active=1, którego nikt nie utworzył, to poważna flaga. Polecenie find pokazuje pliki dotykane w ostatnich 30 dniach — dopasuj każdy z nich do prac, które faktycznie wykonywałeś. Żadne z tych poleceń samo w sobie nie dowodzi przejęcia sklepu, ale wszystko niewyjaśnione w tym miejscu jest dokładnie tym „użytecznym sygnałem”, który warto eskalować.

Uczciwa część: najpierw diagnoza, dopiero potem zakup

To moment, który większość ofert bezpieczeństwa pomija. Właściwą reakcją na te sygnały prawie nigdy nie jest „kup produkt”. Jest nią „dowiedz się, co faktycznie jest nie tak”. Czasem naprawa dotyczy konfiguracji albo hostingu — źle skonfigurowanego serwera, brakującego WAF, ujawnionego serwera źródłowego — i wtedy właściwym krokiem jest audyt hostingu, nie moduł. Czasem chodzi o utwardzenie: zamknięcie ścieżki administracyjnej, dodanie ograniczania prób logowania i 2FA; wtedy moduł z otwartym kodem, taki jak Security Revolution, ma sens — ale dopiero po potwierdzeniu, że właśnie tu jest luka. A czasem potrzebne jest sprzątanie, bo coś już weszło do środka, i to jest osobne, skoncentrowane zadanie.

Właśnie dlatego warto najpierw wykonać audyt bezpieczeństwa: mapuje Twoje realne narażenie i mówi, na której z tych trzech dróg faktycznie jesteś, żebyś nie wydawał pieniędzy na rozwiązywanie problemu, którego nie masz. Zaczynasz od wpisania adresu URL sklepu na stronie audytu bezpieczeństwa; pod tym adresem uruchamiany jest test gotowości tylko do odczytu i dopiero potem zamawiany jest audyt.

Jeśli przekazanie dostępu budzi Twój niepokój — powinno — ten instynkt jest słuszny, dlatego zbudowaliśmy proces wokół niego. Audyt jest wykonywany w trybie tylko do odczytu: patrzymy, nie zapisujemy i nigdy nie dotykamy Twojej bazy danych klientów. Dokładnie opisaliśmy, co to oznacza oraz do czego mamy i nie mamy dostępu, w naszym przewodniku przygotowania sklepu do audytu; warto go przeczytać przed zamówieniem, żeby precyzyjnie wiedzieć, na co się zgadzasz. Bezpieczeństwo i wydajność często idą razem, więc jeśli już mapujesz kondycję sklepu, warto równolegle spojrzeć na szersze usługi eksperckie oraz audyt wydajności.

Wykonaj dziś dziesięciominutowy test. Jeśli wynik jest czysty, ciesz się spokojem — zasłużyłeś na niego za darmo. Jeśli nie jest, wiesz już wystarczająco dużo, żeby zadać właściwe pytanie, a to jest warte znacznie więcej niż jakikolwiek pojedynczy produkt.

Najczęściej zadawane pytania

Czy audyt bezpieczeństwa usuwa infekcję, czy tylko ją znajduje?

Audyt diagnozuje — mapuje narażenie sklepu i mówi, czy coś już dostało się do środka. Czyszczenie to osobne, skoncentrowane zadanie, bo bezpieczne usunięcie backdoora oznacza znalezienie wszystkich punktów wejścia, nie tylko tego, który zauważyłeś, a potem zamknięcie luki, która go wpuściła, żeby nie wrócił. To audyt mówi, czy w ogóle potrzebujesz czyszczenia i jak głęboko trzeba wejść. Do obietnic w stylu „przeskanujemy i naprawimy wszystko za jednym razem” podchodź ostrożnie; cichy, trwały backdoor rzadko znika tak czysto.

Mam aktualne PrestaShop 8 i wszystko zaktualizowane. Czy nadal potrzebuję audytu?

Możliwe, że nie — i to dobra sytuacja. Aktualny rdzeń oraz zaktualizowane moduły usuwają największe, najczęściej skanowane ryzyka. Pozostałe pytania, na które odpowiada audyt, to te, których aktualizacje nie obejmują: czy adres IP serwera źródłowego wycieka mimo CDN, czy ścieżkę panelu da się atakować brute force, czy masz monitorowanie integralności plików i przetestowaną kopię zapasową poza serwerem oraz czy nie zatrzymujesz więcej danych klientów, niż powinieneś. Jeśli dziesięciominutowy test także w tych punktach jest czysty, sklep naprawdę jest w dobrej kondycji.

Czy będziecie potrzebować mojego hasła administratora albo kopii bazy danych?

Nie. Audyt bezpieczeństwa zaczyna się od samego adresu URL sklepu i w dużej mierze działa z zewnątrz do środka. Tam, gdzie kontrola wymaga zajrzenia do panelu administracyjnego, wystarczy konto pracownika tylko do odczytu, a my nigdy nie prosimy o kopię danych klientów ani zamówień i jej nie pobieramy. Pełny model dostępu opisuje przewodnik przygotowania sklepu do audytu — przeczytaj go przed zamówieniem, żeby dokładnie wiedzieć, co obejmuje proces.

Jak odróżnić realne przejęcie sklepu od fałszywego alarmu w samodzielnym teście?

Często nie da się tego zrobić samodzielnie i to jest uczciwa granica takiego testu — ma podnosić flagi, nie potwierdzać je ostatecznie. Ostatnio zmodyfikowany plik może być legalną aktualizacją; nieznany pracownik może być byłym podwykonawcą. Zadaniem samodzielnego testu jest powiedzieć Ci, czy trzeba przyjrzeć się sprawie mocniej. Kiedy pojawia się coś niewyjaśnionego i nie potrafisz tego przypisać do znanej pracy, to jest moment, w którym zewnętrzny przegląd zaczyna się zwracać, bo potwierdzenie „tu jest w porządku” ma taką samą wartość jak potwierdzenie „tu nie jest”.

Jak często uruchamiać samodzielny test?

Dziesięciominutowa wersja jest na tyle tania, że warto uruchamiać ją kwartalnie oraz po każdej większej zmianie — aktualizacji PrestaShop, nowym module płatności, zmianie szablonu albo rotacji personelu, która dotyczyła dostępu administracyjnego. Dwie kontrole, które warto zautomatyzować zamiast powtarzać ręcznie, to monitorowanie integralności plików i przetestowane kopie zapasowe poza serwerem; gdy działają stale, większość reszty sprowadza się do potwierdzenia, że nic nie odpłynęło od oczekiwanego stanu.

Powiązane artykuły

• Czy Twój sklep PrestaShop działa wolno? Najpierw zmierz, potem optymalizuj
• Czy udostępnienie audytorowi dostępu do sklepu PrestaShop jest bezpieczne?
• Przedstawiamy Expert Services: audyty PrestaShop, zanim kupisz kolejny moduł
• Jak sprawdzić, czy Twój sklep PrestaShop potrzebuje audytu SEO
• PrestaShop SEO: kompletny przewodnik po wyższych pozycjach