W 2026 roku liczba obsługiwanych incydentów bezpieczeństwa e-commerce w Polsce przekroczy, według prognoz, 150 tysięcy rocznie. PrestaShop jest częstym celem nie dlatego, że jest mniej bezpieczny niż inne platformy — dlatego, że jest popularny. Popularność oznacza więcej sklepów do zaatakowania jednym, sprawdzonym schematem. Znaleziono już moduły z Marketplace z podatnościami ocenionymi na CVSS 9.8 — czyli krytycznymi, wykorzystywalnymi bez logowania, samym wywołaniem odpowiedniego adresu URL. Jeśli instalujecie moduły firm trzecich bez żadnej weryfikacji, statystycznie zwiększacie ryzyko, nie tylko funkcjonalność sklepu. Poniżej pokazujemy, co konkretnie sprawdzić, zanim moduł trafi na produkcję.
Dlaczego moduły, nie rdzeń, są najczęstszym wektorem ataku
Rdzeń PrestaShop przechodzi regularne audyty bezpieczeństwa i dostaje szybkie poprawki, gdy coś zostanie znalezione. Moduły firm trzecich — z Marketplace albo spoza niego — nie mają tej samej gwarancji. Jakość kodu, częstotliwość aktualizacji i reakcja na zgłoszone podatności zależą od tego, kto dany moduł napisał i czy wciąz go wspiera.
Realny przykład z historii PrestaShop: część modułów trafiła do sprzedaży z pozostawionym w pakiecie folderem phpunit — elementem środowiska testowego, który nigdy nie powinien trafić na produkcję, a który dawał potencjalny dostęp do wykonania kodu na serwerze. To nie była wina rdzenia platformy — to był błąd konkretnych autorów modułów, niezauważony do momentu, aż ktoś to sprawdził.
Co konkretnie sprawdzić przed instalacją modułu
- Data ostatniej aktualizacji. Moduł, który nie był aktualizowany od dawna, może być po prostu porzucony przez autora — a porzucone dodatki są jednym z najczęściej wykorzystywanych punktów wejścia, bo nikt już nie łata w nich znalezionych luk.
- Obecność plików i folderów niezwiązanych z działaniem modułu — folderów testowych, przykładowych plików konfiguracyjnych, pozostałości po środowisku deweloperskim autora. To dokładnie ten typ błędu, który stał za incydentem z folderem phpunit.
- Kod zaciemniony (np. przez ionCube) bez dokumentacji. Zaciemnienie samo w sobie nie jest niebezpieczne, ale utrudnia wykrycie, co moduł faktycznie robi — a to problem, jeśli robi coś więcej, niż deklaruje.
- Zakres żądanych uprawnień i dostępu. Moduł do prostej funkcji frontowej (np. formularz zapytania ofertowego) nie powinien potrzebować szerokiego dostępu do bazy danych czy plików systemowych.
- Kolizje z hookami i innymi modułami. Kilka modułów zaczepionych o ten sam hook może wchodzić w konflikt, prowadząc do nieprzewidzianych zachowań, trudnych do zdiagnozowania później.
Magecart — zagrożenie specyficzne dla e-commerce, nie tylko dla PrestaShop
Magecart to złośliwy skrypt umieszczany bezpośrednio na stronie płatności, kradnący dane kart kredytowych klientów w czasie rzeczywistym, w momencie ich wpisywania. Nowoczesne wersje tego skryptu są zaprojektowane, żeby unikać wykrycia przez programistów — jeśli skrypt zauważy otwartą konsolę developerską w przeglądarce, po prostu się nie ładuje, żeby nie zostać zauważonym podczas standardowej kontroli.
To zagrożenie szczególnie związane z modułami obsługującymi checkout i płatności — dokładnie tam, gdzie moduł firmy trzeciej ma bezpośredni dostęp do danych najbardziej wrażliwych dla klienta. Audyt modułów płatniczych i checkoutowych zasługuje na szczególną uwagę, większą niż moduł odpowiadający za, na przykład, wygląd bannera na stronie głównej.
Proces audytu przed wdrożeniem na produkcję
- Instalujcie najpierw na środowisku testowym, nigdy bezpośrednio na produkcji, niezależnie od tego, jak zaufane wydaje się źródło modułu.
- Sprawdźcie kod statycznie przed pierwszym uruchomieniem, szczególnie pod kątem podejrzanych wywołań sieciowych do zewnętrznych adresów niezwiązanych z deklarowaną funkcją modułu.
- Monitorujcie ruch sieciowy modułu po instalacji na środowisku testowym — nieoczekiwane połączenia wychodzące do nieznanych serwerów to poważny sygnał ostrzegawczy.
- Dokumentujcie, jakie moduły macie zainstalowane i po co. Sklep, w którym nikt nie pamięta, dlaczego zainstalowano dany moduł trzy lata temu, jest trudny do bezpiecznie zaudytowania i zaktualizowania.
Co robić z modułami porzuconymi przez autorów
Moduł, który przestał być wspierany, nie przestaje działać z dnia na dzień — ale przestaje otrzymywać poprawki, gdy ktoś znajdzie w nim podatność. To ryzyko narastające w czasie, nie jednorazowe. Praktyczne podejście: zidentyfikujcie takie moduły podczas audytu, oceńcie, czy funkcja, którą zapewniają, jest wciąż potrzebna, i jeśli tak — znajdźcie aktywnie wspierany zamiennik albo rozważcie napisanie prostego, dedykowanego modułu zamiast dalszego korzystania z nieaktualizowanego kodu firmy trzeciej.
Przykład z praktyki (Klient J, sklep B2B z branży chemii budowlanej — przykład poglądowy, dane uśrednione dla tej skali projektu)
Firma korzystała z modułu rozbudowującego kartę produktu o dodatkowe zakładki techniczne, zainstalowanego kilka lat wcześniej i od tego czasu nieaktualizowanego. Audyt bezpieczeństwa wykazał, że moduł ten miał publicznie znaną, krytyczną podatność, wykorzystywalną bez logowania — dokładnie ten typ ryzyka, jaki opisujemy w tym artykule.
Ponieważ funkcja modułu wciąż była potrzebna, ale sam moduł nie miał już wsparcia autora, firma zdecydowała się na zastąpienie go prostym, dedykowanym rozszerzeniem zbudowanym wokół systemu hooków, bez zbędnych, niewykorzystywanych funkcji, które rozszerzały niepotrzebnie powierzchnię ataku. Nowe rozwiązanie robiło mniej, ale robiło to bezpiecznie i pod pełną kontrolą firmy.
FAQ
Czy moduł z oficjalnego PrestaShop Marketplace jest z definicji bezpieczny? Nie automatycznie. Marketplace weryfikuje moduły przed publikacją, ale nie gwarantuje, że kod pozostanie bezpieczny na zawsze — nowe podatności bywają odkrywane po publikacji, a nie każdy autor szybko reaguje aktualizacją.
Jak sprawdzić, czy moduł, którego już używamy, ma znane podatności? Warto regularnie sprawdzać publiczne bazy podatności (np. bazy CVE) w połączeniu z datą ostatniej aktualizacji modułu, oraz rozważyć profesjonalny audyt bezpieczeństwa, jeśli sklep ma wiele niestandardowych modułów zainstalowanych na przestrzeni lat.
Czym jest atak Magecart i dlaczego dotyczy modułów checkoutowych? To złośliwy skrypt kradnący dane kart płatniczych w czasie rzeczywistym, umieszczany na stronie płatności — często przez skompromitowany moduł lub integrację mającą dostęp do tej części sklepu. Moduły obsługujące checkout wymagają szczególnie dokładnego audytu.
Co robić z modułem, który przestał być wspierany przez autora? Ocenić, czy jego funkcja jest wciąż potrzebna. Jeśli tak, poszukać aktywnie wspieranego zamiennika albo zbudować prosty, dedykowany moduł zamiast dalej korzystać z nieaktualizowanego kodu, który z czasem staje się coraz większym ryzykiem.
Jak często warto audytować moduły zainstalowane w sklepie PrestaShop? Co najmniej raz w roku, oraz dodatkowo przy każdej większej aktualizacji platformy — migracja na nową wersję to naturalny moment, żeby sprawdzić, które moduły są wciąż potrzebne, aktualne i bezpieczne.
Nie jesteście pewni, czy moduły zainstalowane w Waszym sklepie PrestaShop są bezpieczne i wciąż wspierane? Sprawdźcie naszą ofertę cyberbezpieczeństwa — jako certyfikowany PrestaShop Expert zaudytujemy zainstalowane moduły i wskażemy, co wymaga natychmiastowej uwagi.
