Jak zabezpieczyć sklep PrestaShop: prosty przewodnik dla właścicieli

Jeśli prowadzisz sklep PrestaShop, a słowo „bezpieczeństwo” wywołuje u Ciebie lekki ścisk w żołądku, ten przewodnik jest dla Ciebie. Nie musisz być programistą. Musisz zrozumieć kilka kluczowych zasad na tyle dobrze, aby podejmować dobre decyzje, i wiedzieć, które zadania możesz wykonać samodzielnie w panelu administracyjnym, a które lepiej przekazać programiście. Właśnie tym jest ten tekst: prostą mapą bezpieczeństwa sklepu PrestaShop, ułożoną według tego, co naprawdę ma znaczenie, z linkami do osobnych, pełnych poradników dla każdego głębszego tematu, aby ta strona nie zamieniła się w ścianę 6000 słów, której nigdy nie doczytasz do końca.

Ostatnia aktualizacja: czerwiec 2026. Tekst przygotowany dla właścicieli sklepów na PrestaShop 1.7, 8 lub 9, nic tutaj nie zakłada konkretnej wersji, a treść aktualizujemy wraz ze zmianami zagrożeń i dat wsparcia PHP.

Najpierw jedna zmiana perspektywy. Nie jesteś celem dlatego, że Twój sklep jest ważny. Jesteś celem dlatego, że bot nie wie i nie obchodzi go, czym jest Twój sklep. Automatyczne skanery przeczesują cały internet w poszukiwaniu dowolnej instalacji WordPressa, Magento lub PrestaShop ze znaną luką, tak jak włamywacz idący ulicą i sprawdzający każdą klamkę. Prawie każdy skuteczny atak, który widzimy, sprowadza się do podstawowych drzwi zostawionych bez zamka, starej wersji, ponownie użytego hasła, pirackiego modułu, a nie do genialnego hakera. To naprawdę dobra wiadomość, bo podstawowe drzwi możesz zamknąć samodzielnie.

Model myślenia: warstwy, nie magiczny przycisk

Nie istnieje jedno ustawienie, które „zabezpiecza” sklep PrestaShop, a każdy produkt obiecujący coś takiego próbuje Ci coś sprzedać. Prawdziwe bezpieczeństwo to warstwy: każda z nich wyłapuje to, co przeszło przez poprzednią. Pomyśl o tym tak, jak o fizycznym sklepie, zamek w drzwiach, do tego kasa opróżniana na noc, ubezpieczenie i kamera. Żadna pojedyncza rzecz nie jest całą odpowiedzią; razem sprawiają, że jedna awaria nie kończy działalności.

W sklepie PrestaShop te warstwy układają się mniej więcej tak, a warto wiedzieć, która za co odpowiada:

Zwróć uwagę, że „możliwość odzyskania sklepu” jest na liście. Specjaliści od bezpieczeństwa mają powiedzenie: to nie kwestia czy, tylko kiedy. Sklep, który można w pełni przywrócić z czystej kopii zapasowej w godzinę, jest w zupełnie innej sytuacji niż taki, którego przywrócić się nie da. Niezależnie od tego, jak dobre ma zabezpieczenia. Dobrze ustaw warstwę odzyskiwania, a każda inna pomyłka staje się możliwa do przeżycia.

Zacznij tutaj: pięć rzeczy, które zatrzymują najwięcej ataków

Jeśli masz zrobić tylko pięć rzeczy, zrób te. Są ułożone według stosunku efektu do wysiłku, a każdą z nich nietechniczny właściciel może wykonać bez programisty.

1. Aktualizuj PrestaShop, PHP i moduły

To nudne, ale jest najważniejszym nawykiem. Stare oprogramowanie przestaje otrzymywać poprawki bezpieczeństwa, co oznacza, że znane dziury pozostają otwarte. PrestaShop publikuje poprawki bezpieczeństwa w wersjach pomniejszych. Używanie 8.1.0, gdy istnieje 8.1.7, oznacza działanie z publicznie opisanymi lukami, które boty już potrafią znaleźć. Sprawdź wersję PHP w panelu administracyjnym w Parametry zaawansowane → Informacje; jeśli widzisz wersję bez wsparcia, taką jak 7.4, poproś hosting o przejście na nowszą wersję. Aktualizacje pomniejsze w tej samej gałęzi (na przykład z 8.1.x do 8.1.x) zwykle są bezpieczne po wykonaniu kopii zapasowej i teście na środowisku testowym. Moduły są równie ważne, podatny moduł to najczęstszy punkt wejścia.

Jeśli utknąłeś na starszej wersji PrestaShop, której nie możesz teraz bezpiecznie zaktualizować, a to realna sytuacja w wielu działających od lat sklepach, istnieją sposoby zamknięcia luk bez aktualizacji. Omawiamy je w poradniku o zaawansowanym utwardzaniu sklepów, których nie możesz jeszcze zaktualizować.

2. Włącz uwierzytelnianie dwuskładnikowe dla każdego administratora

PrestaShop nie zapewnia uniwersalnego, wbudowanego 2FA w instalacjach 1.7/8; dodaj je za pomocą zaufanego modułu albo zewnętrznej warstwy tożsamości/bezpieczeństwa. Oznacza to, że nawet jeśli ktoś ukradnie Twoje hasło, nadal nie zaloguje się bez kodu z Twojego telefonu. Konfiguracja zajmuje około pięciu minut z aplikacją taką jak Google Authenticator lub Authy. Włącz to dla każdego konta pracownika, nie tylko swojego. Pracownik ze słabym hasłem i bez 2FA jest najsłabszym ogniwem, a atakujący zawsze idą po najsłabsze ogniwo. Pełną instrukcję krok po kroku, wraz z politykami haseł dla panelu administracyjnego, znajdziesz w tekście o 2FA, politykach haseł i bezpieczeństwie administracji w PrestaShop.

3. Upewnij się, że HTTPS naprawdę działa

Prawie każdy sklep ma dziś certyfikat SSL, ale „kłódka w przeglądarce” nie oznacza „pełnego bezpieczeństwa”. Kłódka potwierdza tylko, że sama strona załadowała się przez HTTPS, nie mówi nic o obrazach ani skryptach wczytywanych po zwykłym http:// (tak zwana mieszana zawartość, którą przeglądarki po cichu blokują, psując elementy bez oczywistego błędu). Nie gwarantuje też, że ktoś wpisujący Twój adres http:// zostanie przekierowany na bezpieczną wersję, zanim PrestaShop w ogóle się załaduje. Obie rzeczy warto zrobić poprawnie. Instrukcja krok po kroku, od włączenia SSL w Parametry sklepu → Ogólne po naprawę mieszanej zawartości i przekierowanie na poziomie serwera, znajduje się w poradniku jak skonfigurować SSL i HTTPS w PrestaShop.

4. Jedna osoba, jedno konto, i najmniejsze niezbędne uprawnienia

Wspólne loginy („wszyscy logują się jako admin”) są jedną z najczęstszych przyczyn incydentów i jedną z najtrudniejszych rzeczy do wyjaśnienia po fakcie, bo nie masz ścieżki audytu. Nie wiesz, kto zmienił cenę, kto usunął produkt ani kto wyeksportował listę klientów o 2:00 w nocy. Utwórz osobne konto dla każdej osoby, która potrzebuje dostępu do panelu administracyjnego, i używaj profili uprawnień PrestaShop (w Parametry zaawansowane → Zespół), aby każda osoba miała tylko to, czego wymaga jej praca. Pracownik obsługi klienta nie potrzebuje ustawień płatności; operator magazynu nie potrzebuje zarządzania pracownikami. To nie biurokracja, to ograniczenie skutków, gdy jedno konto zostanie przejęte. Raz na kwartał sprawdzaj listę i usuwaj konta osób, które odeszły.

5. Nie instaluj oprogramowania, któremu nie możesz ufać, i usuń to, czego nie używasz

Moduły to najczęstsze drzwi, przez które przechodzą atakujący, a podatny moduł może zostać wykorzystany nawet wtedy, gdy aktywnie z niego nie korzystasz. Dwie zasady ograniczają większość ryzyka. Po pierwsze: instaluj moduły tylko ze źródeł, którym ufasz, oficjalnej platformy PrestaShop Addons albo od sprawdzonych deweloperów z realnym wsparciem i historią działania. Pirackie moduły (płatne moduły złamane i rozdawane za darmo) prawie zawsze zawierają tylne wejście; ekonomia mówi sama za siebie, nikt nie rozdaje płatnego oprogramowania za darmo z dobroci serca. Po drugie: usuwaj moduły, których nie używasz. Nie tylko wyłączaj. Wyłączone moduły nadal mogą zostawiać dostępne pliki na dysku, więc odinstaluj i usuń nieużywane moduły, aby zdjąć tę powierzchnię ataku. Jeśli nie używałeś modułu przez sześć miesięcy i nie będziesz go używać, powinien zniknąć.

Następna warstwa: ruch, o który nie prosiłeś

Gdy podstawy są już zamknięte, kolejną rzeczą, którą zauważa większość właścicieli, jest niechciany ruch, boty bombardujące stronę logowania, roboty kopiujące treści, spam przez formularze kontaktowe i opinie, czasem nadużywający użytkownik. Żadna z tych spraw nie wymaga programisty; to głównie konfiguracja i właściwe narzędzia.

• Złe boty i niechciane roboty indeksujące. Nie wszystkie boty są złe (bot Google to bot, którego chcesz), więc celem jest filtrowanie, nie blokowanie wszystkiego jak leci. Praktyczne instrukcje znajdziesz w poradniku kontrola odwiedzających: blokowanie złych botów i niechcianego ruchu.
• Problemowe osoby. Gdy chodzi o konkretną osobę, oszusta, seryjne obciążenia zwrotne, agresywnego klienta, chcesz zapisywać dodatkowe informacje przy zamówieniach i blokować po IP. Opisujemy to w tekście o dodatkowych informacjach o klientach i blokadach IP.
• Spam w formularzach. Formularze kontaktowe, rejestracja kont i opinie przyciągają spam botów. reCAPTCHA zatrzymuje boty bez zmuszania prawdziwych klientów do skakania przez przeszkody, zobacz reCAPTCHA dla PrestaShop.
• Zalew wyszukiwania fasetowego „?q=”. To bardziej techniczny problem, o którym warto wiedzieć: agresywne roboty mogą zamienić filtry nawigacji warstwowej PrestaShop w przypadkowe obciążenie typu odmowa usługi. Jeśli Twój sklep zwalnia pod ruchem botów, przeczytaj jak przetrwać zalew ?q=.

Warstwa serwerowa (tu możesz chcieć pomocy)

Część utwardzania odbywa się poniżej PrestaShop, na poziomie serwera WWW i systemu plików. Możesz zrobić to samodzielnie, ale to warstwa, przy której najbardziej rozsądnie jest poprosić hosting lub programistę, jeśli nie masz pewności. Błędna reguła .htaccess może wyłączyć stronę.

Wersja krótka: uprawnienia plików powinny wynosić 755 dla katalogów i 644 dla plików, nigdy 777, a plik przechowujący hasło do bazy danych (app/config/parameters.php w PrestaShop 1.7 i 8 albo config/settings.inc.php w starszym 1.6) powinien być zablokowany jeszcze mocniej. Twój .htaccess powinien blokować bezpośredni publiczny dostęp do folderów takich jak /app/config/, /var/ i /vendor/, a także uniemożliwiać wykonywanie PHP w folderach na przesyłane pliki, tak aby jeśli coś paskudnego zostanie przesłane, nie mogło się uruchomić. Domyślny .htaccess PrestaShop jest punktem wyjścia, nie gotową konfiguracją. Pełny zestaw reguł, gotowy do skopiowania, znajdziesz w PrestaShop .htaccess: reguły bezpieczeństwa i wydajności.

Przy dostępie do Apache/vhost reguła blokująca wykonywanie przesłanych plików powinna być jawna. Poniższe ścieżki odpowiadają częstemu katalogowi głównemu dokumentów PrestaShop; dostosuj je do swojego serwera.

# Apache: stop uploaded PHP from executing
<Directory "/var/www/html/img">
    php_admin_flag engine off
    <FilesMatch "\.php$">
        Require all denied
    </FilesMatch>
</Directory>

<Directory "/var/www/html/upload">
    php_admin_flag engine off
    <FilesMatch "\.php$">
        Require all denied
    </FilesMatch>
</Directory>

Panel jest użyteczny dopiero wtedy, gdy podstawowe darmowe utwardzenie jest już wdrożone.

Jeśli chcesz zrozumieć typ ataku, przed którym broni całe to utwardzanie serwera, jak rzeczywisty skimmer kart trafia do sklepu PrestaShop i kradnie dane płatnicze, instrukcja w tekście anatomia ataku w stylu Magecart przekłada abstrakcję na konkret. Warto przeczytać ją raz, choćby po to, żeby reszta przestała brzmieć teoretycznie.

Warstwa odzyskiwania: kopie zapasowe, które faktycznie testowałeś

Kopie zapasowe nie są środkiem bezpieczeństwa. Są środkiem odzyskiwania, a to rozróżnienie zmienia sposób, w jaki należy je traktować. Żadna kopia zapasowa nie zatrzyma ataku. Dobre kopie zapasowe sprawiają, że atak nie kończy Twojej firmy. Trzy nawyki odróżniają prawdziwą strategię kopii zapasowych od jej pozorów:

• Zautomatyzuj to. Ręczne kopie zapasowe są pomijane i zapominane. Nocny cron, który zrzuca bazę danych i kopiuje ją poza serwer, w miejsce, którego przejęcie serwera WWW nie może jednocześnie wyczyścić, to absolutna podstawa.
• Testuj przywracanie. Kopia zapasowa, której nigdy nie przywróciłeś, jest tylko plikiem o nieznanej zawartości. Raz na kwartał przywróć ją na środowisku testowym. Nie chcesz, aby pierwsze przywracanie w Twoim życiu odbywało się podczas prawdziwego incydentu.
• Trzymaj wiele punktów przywracania. Codziennie z ostatniego miesiąca, co tydzień przez sześć miesięcy. Niektóre ataki, zwłaszcza ciche manipulacje w bazie danych, są zauważane dopiero po tygodniach, a wtedy potrzebujesz punktu sprzed momentu, w którym się zaczęły.

Jeśli wydarzy się najgorsze

Nawet dobrze zabezpieczony sklep może zostać naruszony, a zły odruch w pierwszej godzinie wyrządza realne szkody, ludzie usuwają pliki (niszcząc dowody, których potrzebują) albo próbują chirurgicznie czyścić złośliwe oprogramowanie, którego nigdy w pełni nie znajdą. Istnieje właściwa kolejność: odizolować, zachować dowody, ustalić punkt wejścia, przywrócić z czystej kopii zapasowej, zmienić wszystkie dane dostępowe i spełnić obowiązki informacyjne (RODO wymaga zgłoszenia w ciągu 72 godzin od stwierdzenia naruszenia dotyczącego danych osobowych). Nie próbuj przypominać sobie tego pod presją, przygotowaliśmy spokojną procedurę krok po kroku, którą możesz wykonać, gdy będzie to naprawdę ważne: co zrobić, jeśli Twój sklep zostanie zhakowany.

Gdzie pasują moduły mypresta.rocks

Większość rzeczy z tej strony kosztuje tylko uwagę, aktualizacje, 2FA, rozsądne uprawnienia, realne kopie zapasowe. Moduł zasługuje na miejsce tam, gdzie warstwy są żmudne albo niemożliwe do ręcznego obsłużenia: ciągłe obserwowanie plików pod kątem zmian, których nie wprowadziłeś, filtrowanie wrogiego ruchu w czasie rzeczywistym oraz utrzymywanie poprawnej obsługi cookie i zgód bez psucia sklepu. Nasze moduły bezpieczeństwa istnieją po to, aby automatyzować dokładnie te zadania, żebyś nie wykonywał ich ręcznie o północy. Korzyść polega na tym, że nietechniczny właściciel ma o jedną rzecz mniej do monitorowania, a zmiany, które inaczej by umknęły, pojawiają się w panelu zamiast w raporcie z incydentu. To warstwa nad darmowymi fundamentami opisanymi tutaj, nie ich zamiennik. Najpierw zamknij darmowe drzwi; po narzędzia sięgaj tam, gdzie coś naprawdę wymaga obserwacji przez całą dobę.

Jeden nawyk, który spina całość

Bezpieczeństwo nie jest funkcją, którą włączasz raz i zapominasz, to utrzymanie, tak jak dbanie o poprawność katalogu czy rzetelne stany magazynowe. Właściciele, którzy unikają problemów, nie są tymi, którzy kupili najwięcej oprogramowania; to ci, którzy ustawili cykliczne przypomnienie. Raz na kwartał, dwadzieścia minut: potwierdź, że PrestaShop i moduły są aktualne, sprawdź, że 2FA jest włączone dla wszystkich, usuń konta byłych pracowników i, co najważniejsze, zweryfikuj, że kopię zapasową da się rzeczywiście przywrócić. Dwadzieścia minut co trzy miesiące jest dramatycznie tańsze niż odzyskiwanie po włamaniu i zmienia cały temat ze źródła lęku w rutynę, o której prawie nie myślisz.

Pytania, które zadają nam właściciele sklepów

Dlaczego ktokolwiek miałby atakować mój mały sklep? Przecież jestem nikim.

Nie atakują Ciebie, atakują wszystkich naraz. Automatyczne skanery przeczesują cały internet, sprawdzając każdą klamkę, tak jak włamywacz idący ulicą. Nie wiedzą i nie obchodzi ich, czym jest Twój sklep; interesuje ich tylko to, czy otwarta jest znana luka. Prawie każdy skuteczny atak, który sprzątamy, sprowadza się do podstawowych drzwi zostawionych bez zamka, starej wersji, ponownie użytego hasła, pirackiego modułu, a nie hakera, który wybrał Cię celowo.

Mam certyfikat SSL i widzę kłódkę. Czy to nie znaczy, że jestem bezpieczny?

Kłódka potwierdza tylko, że oglądana strona załadowała się przez HTTPS. Nie mówi nic o obrazach ani skryptach wczytywanych po zwykłym http:// (które przeglądarki po cichu blokują, psując elementy bez oczywistego błędu), i nie gwarantuje, że ktoś wpisujący Twój adres http:// zostanie przekierowany na bezpieczną wersję, zanim cokolwiek się załaduje. HTTPS to jedna z wielu warstw, konieczna, ale niewystarczająca. Instrukcję krok po kroku, jak zrobić to w pełni poprawnie, znajdziesz w poradniku jak skonfigurować SSL i HTTPS w PrestaShop.

Czy darmowe moduły z przypadkowych stron naprawdę są aż tak niebezpieczne?

Niebezpieczne są pirackie moduły, płatne moduły złamane i rozdawane za darmo. Prawie zawsze niosą tylne wejście; ekonomia mówi sama za siebie, bo nikt nie rozdaje płatnego oprogramowania za darmo z dobroci serca. Darmowe moduły z oficjalnej platformy PrestaShop Addons albo od sprawdzonego dewelopera z realnym wsparciem są w porządku. Zasada dotyczy źródła, któremu ufasz, nie ceny.

Jeśli zostanę zhakowany, czy nie mogę po prostu usunąć złych plików i iść dalej?

To odruch, który wyrządza najwięcej szkód. Usuwanie plików niszczy dowody potrzebne do ustalenia, jak doszło do wejścia, a chirurgiczne czyszczenie złośliwego oprogramowania prawie zawsze coś pomija. Istnieje właściwa kolejność, odizolować, zachować dowody, znaleźć punkt wejścia, przywrócić z czystej kopii zapasowej, zmienić wszystkie dane dostępowe i spełnić obowiązki informacyjne (RODO daje 72 godziny od stwierdzenia naruszenia danych osobowych). Skorzystaj ze spokojnej wersji w poradniku co zrobić, jeśli Twój sklep zostanie zhakowany, zamiast improwizować pod presją.

Jaka jest jedna najcenniejsza rzecz, którą mogę zrobić?

Dwie, i obie tanie: aktualizuj PrestaShop, PHP i moduły oraz upewnij się, że masz kopię zapasową, którą naprawdę przynajmniej raz przywróciłeś. Pierwsza rzecz zatrzymuje większość ataków; druga sprawia, że te, które przejdą, nie kończą Twojej firmy. Cała reszta to warstwy zbudowane na tych dwóch fundamentach.

Czytaj dalej

• Utwardzanie bezpieczeństwa PrestaShop: kompletna checklista, ten sam zakres w formie listy do odhaczania, gdy znasz już pojęcia.
• Anatomia ataku w stylu Magecart na sklep PrestaShop 1.7.x, prawdziwy incydent ze skimmerem kart, omówiony krok po kroku, aby abstrakcja przestała brzmieć teoretycznie.
• Zaawansowane utwardzanie sklepów, których nie możesz jeszcze zaktualizować. Zamykanie luk, gdy aktualizacja nie jest teraz możliwa.

Jeśli chcesz ten sam zakres jako listę do odhaczania, przez którą można przejść od razu, zamiast przewodnika z wyjaśnieniami, tekstem towarzyszącym jest kompletna checklista utwardzania bezpieczeństwa PrestaShop. Zacznij tam, jeśli znasz już pojęcia i chcesz tylko upewnić się, że nic nie zostało pominięte.