Utwardzanie zabezpieczeń PrestaShop: pełna lista kontrolna

Sklep PrestaShop jest kuszącym celem z prostego powodu: znajduje się na styku pieniędzy i danych osobowych. Obsługuje płatności kartą, imiona i nazwiska klientów, adresy, historię zamówień oraz panel administracyjny dostępny z dowolnego miejsca w internecie. Większość ataków, które w niego uderzają, nie jest szczególnie wyrafinowana — są zautomatyzowane, masowe i szukają jednego pola, którego zapomniano odhaczyć. Ta strona jest właśnie taką listą pól. To główna lista kontrolna utwardzania sklepu PrestaShop, ułożona tak, aby najpierw wykonać działania o największym efekcie i najmniejszym nakładzie pracy, a każdy głębszy temat odesłać do poradnika, który omawia go porządnie.

Zweryfikowano w czerwcu 2026 r. Te zabezpieczenia dotyczą PrestaShop 1.7, 8 i 9 (back office PS9 działa na Symfony 6.4); aktualizujemy tę listę wraz ze zmianami komunikatów bezpieczeństwa i terminów wsparcia PHP.

Traktuj ją jak listę kontrolną, nie jak esej. Idź od góry: pozycje z Poziomu 1 zamykają drzwi, którymi codziennie szarpią automatyczne skanery, a większość z nich da się wykonać w jedno popołudnie z poziomu back office albo panelu hostingowego. Jeśli chcesz przejść przez ten sam temat prostym językiem, bez żargonu, zacznij od naszego prostego poradnika dla właścicieli sklepów, a potem wróć tutaj po pełny przegląd.

Jak korzystać z tej listy kontrolnej

Każda pozycja poniżej to konkretne zabezpieczenie z jasnym właścicielem i jasnym efektem. Tam, gdzie temat jest na tyle obszerny, że zasługuje na osobny przewodnik — konfiguracja 2FA, reguły .htaccess, SSL, blokowanie botów — ta strona daje Ci akapit „co i dlaczego”, a potem prowadzi do instrukcji krok po kroku. Taki układ centrum i powiązanych poradników jest celowy: tutaj widzisz całą mapę, bez tłumaczenia reCAPTCHA po raz piąty, a po link sięgasz wtedy, gdy faktycznie konfigurujesz dane zabezpieczenie.

Jedna uwaga na start: większość tych działań służy zmniejszeniu powierzchni ataku (mniej drzwi), a część dotyczy wykrywania i odzyskiwania, gdy coś jednak się przedrze (alarmy i wyjścia awaryjne). Bezpieczny sklep potrzebuje obu warstw. Sklep z 16-znakowym hasłem administratora i bez kopii zapasowych dzieli tylko jedna zła aktualizacja modułu od bardzo złego tygodnia.

Poziom 1 — podstawy (zrób to w tym tygodniu)

1. Zmień nazwę katalogu administracyjnego

PrestaShop już domyślnie tworzy folder administracyjny z losowym sufiksem (na przykład admin8f3k2) właśnie z tego powodu — ale wiele sklepów po aktualizacjach ze starszych wersji nadal działa pod przewidywalnym adresem /admin albo /adminXXXX, który skanery sprawdzają jako pierwszy. Zmień nazwę folderu przez FTP/SFTP albo menedżer plików hostingu na taką, której nikt nie odgadnie (unikaj oczywistych słów typu backoffice, manage czy panel — one też są skanowane). PrestaShop wykryje zmianę przy następnym logowaniu; potem zaktualizuj zakładkę i przekaż nowy URL zespołowi. Co z tego wynika? Największym źródłem ruchu brute force na panel administracyjny są boty uderzające w przewidywalne adresy logowania. Przesuń drzwi, a większość z nich nigdy ich nie znajdzie.

2. Silne, unikalne hasła administratorów — i porządki na liście kont

Każde konto w back office powinno używać długiego, unikalnego hasła (16+ znaków), wygenerowanego i zapisanego w menedżerze haseł, nigdy używanego gdzie indziej. Równie ważne: otwórz Parametry zaawansowane → Zespół → Pracownicy i usuń każde konto, które nie potrzebuje już dostępu. Uśpione konto administracyjne byłego freelancera to czysta powierzchnia ataku bez żadnej korzyści. Przy okazji sprawdź, czy nikt po cichu nie utworzył konta, którego nie rozpoznajesz.

3. Wymuś HTTPS wszędzie

Uruchamianie finalizacji zamówienia i logowania przez zwykłe HTTP w 2026 roku nie jest ryzykiem, które się akceptuje — to błąd, który trzeba naprawić. HTTPS chroni dane logowania, dane kart i informacje osobowe w trakcie transmisji, a PrestaShop ma wbudowane przełączniki wymuszające go w sekcji Parametry sklepu → Ogólne → Włącz SSL oraz Włącz SSL na wszystkich stronach. Jeśli certyfikat nie jest jeszcze zainstalowany i wymuszony w całej witrynie, przejdź przez nasz poradnik konfiguracji SSL i HTTPS — obejmuje instalację certyfikatu, dwa przełączniki PrestaShop oraz naprawę ostrzeżeń o mieszanej zawartości, na których wiele osób się potyka.

4. Aktualizuj PrestaShop i PHP

Przytłaczająca większość przejętych sklepów PrestaShop działała na wersji z publicznie znaną, już załataną podatnością. Korzystaj ze wspieranej wersji, subskrybuj komunikaty bezpieczeństwa PrestaShop i nigdy nie uruchamiaj wersji PHP po zakończeniu wsparcia bezpieczeństwa (7.4 i 8.0 są już poza tym okresem). Przed każdą aktualizacją rdzenia: wykonaj pełną kopię zapasową, przetestuj zmianę na kopii stagingowej i potwierdź zgodność modułów. Co z tego wynika? Aktualizacje nie są efektowne, ale „byliśmy jedną wersję do tyłu” to najczęstsze zdanie w analizach po naruszeniu bezpieczeństwa.

5. Ogranicz informacje ujawniane przez strony błędów i nagłówki

Upewnij się, że tryb debugowania jest wyłączony na produkcji — potwierdź, że _PS_MODE_DEV_ ma wartość false w pliku config/defines.inc.php, i sprawdź, czy Parametry zaawansowane → Wydajność → Tryb debugowania jest wyłączony — aby stack trace nigdy nie podał atakującemu ścieżek plików, prefiksu tabel ani wersji bibliotek. Ujawniona strona debugowania to darmowa mapa Twojej instalacji.

Poziom 2 — kontrola dostępu

6. Włącz uwierzytelnianie dwuskładnikowe dla back office

2FA oznacza, że samo skradzione hasło administratora nie wystarczy do logowania — atakujący potrzebuje jeszcze kodu z Twojego telefonu. To jednym ruchem zamyka drogę atakom typu credential stuffing i phishingowi, a jednocześnie jest najbardziej wartościową kontrolą dostępu, jaką możesz dodać. Pełna konfiguracja, wraz z polityką haseł i utwardzeniem sesji, ma osobny poradnik: uwierzytelnianie dwuskładnikowe, polityki haseł i bezpieczeństwo administracji w PrestaShop.

7. Ograniczaj tempo i blokuj nieudane logowania

Narzędzia brute force próbują tysięcy haseł. Ogranicz je: ustaw tymczasową blokadę po kilku nieudanych próbach (częsta polityka to 15-minutowa blokada po pięciu błędach, dłuższa blokada albo ban IP po dwudziestu). PrestaShop sam z siebie nie ogranicza agresywnie logowań administratora, więc zwykle robi się to na poziomie WAF/edge albo za pomocą modułu bezpieczeństwa.

8. Ogranicz dostęp do administracji po adresie IP

Jeśli zespół loguje się ze stałych adresów (biuro, dom, wyjście VPN), ogranicz katalog administracyjny do tych IP regułą .htaccess (Require ip ... na Apache) albo zaporą. Jedno takie zabezpieczenie od razu eliminuje większość ruchu brute force i credential stuffing, ponieważ żądania atakującego nigdy nie docierają do formularza logowania. Dokładne reguły znajdziesz w naszym poradniku bezpieczeństwa i wydajności .htaccess.

9. Zaostrz uprawnienia pracowników

System profili PrestaShop w sekcji Parametry zaawansowane → Zespół → Uprawnienia jest szczegółowy — korzystaj z niego. Redaktor treści nie potrzebuje zarządzania modułami; pracownik obsługi klienta nie potrzebuje ustawień serwera ani SQL Managera. Daj każdemu profilowi minimum potrzebnych uprawnień, a potem cyklicznie audytuj listę pracowników i usuwaj osoby, które odeszły. Zasada najmniejszych uprawnień sprawia, że jedno przejęte konto pracownika nie może spalić całego sklepu.

Poziom 3 — utwardzanie serwera i plików

W nginx odpowiednikiem jest reguła odmawiająca dostępu do wrażliwych folderów aplikacji i przesłanych plików PHP. Ścieżki różnią się zależnie od układu hostingu, więc najpierw przetestuj konfigurację poleceniem nginx -t i żądaniem na środowisku stagingowym.

location ~* ^/(app|var|vendor|config|classes|controllers|override)/ {
    deny all;
}

location ~* /(img|upload)/.*\.php$ {
    deny all;
}

Po utwardzeniu reguły serwera i nagłówki bezpieczeństwa należy sprawdzić razem.

10. Ustaw prawidłowe uprawnienia plików

Katalogi powinny mieć uprawnienia 755, a pliki 644. Nic w instalacji PrestaShop nigdy nie powinno mieć 777 (zapis dla wszystkich) — jeśli poradnik każe Ci wykonać chmod 777, żeby „zadziałało”, to problemem jest ten poradnik. Pliki zapisywalne przez wszystkich są dokładnie tym, czego exploit przesyłania plików potrzebuje, aby zostawić backdoora.

11. Zablokuj bezpośredni dostęp WWW do wrażliwych katalogów

Kilka folderów PrestaShop nigdy nie powinno być dostępnych z przeglądarki: /app/, /cache/, /config/, /var/, /vendor/, /translations/, /mails/ i podobne. Dostarczany z PrestaShop plik .htaccess obejmuje część z nich, ale zweryfikuj to i dodaj brakujące reguły (oraz potwierdź, że ustawiono Options -Indexes, aby wyłączyć listowanie katalogów, które w przeciwnym razie ujawnia dokładną listę modułów każdemu ciekawskiemu). Pełny zestaw reguł — wrażliwe katalogi, listowanie, pliki dotfiles — znajdziesz w poradniku bezpieczeństwa i wydajności .htaccess.

12. Dodaj nagłówki bezpieczeństwa HTTP

Nagłówki bezpieczeństwa informują przeglądarkę, aby włączyła dodatkowe zabezpieczenia. Najważniejszy zestaw dla sklepu PrestaShop to: X-Content-Type-Options: nosniff, X-Frame-Options: SAMEORIGIN (ochrona przed clickjackingiem), Strict-Transport-Security (dodaj dopiero wtedy, gdy HTTPS działa solidnie — patrz punkt 3), Referrer-Policy: strict-origin-when-cross-origin oraz Content-Security-Policy, wdrażane najpierw w trybie report-only, żeby nie zepsuć skryptów własnego motywu. Szczególnie CSP jest Twoją najmocniejszą obroną przed skimmerem kart, który wstrzykuje obcy skrypt do finalizacji zamówienia — dokładnie tak przebiega atak opisany w naszym przewodniku anatomia ataku w stylu Magecart na PrestaShop.

13. Postaw WAF przed sklepem

Zapora aplikacji webowych filtruje złośliwy ruch, zanim dotknie PrestaShop. Darmowy plan Cloudflare blokuje wiele typowych wzorców i dodaje ochronę DDoS; Cloudflare Pro i ModSecurity (z OWASP Core Rule Set) idą dalej. WAF jest też pierwszą linią obrony przed presją wolumetryczną i ruchem generowanym przez crawlery — w tym zalewem ?q= z wyszukiwania fasetowego, który może po cichu zamienić własne adresy filtrów PrestaShop w samoczynny atak odmowy usługi. Rozkładamy go na części i bronimy regułami Cloudflare w poradniku jak przetrwać zalew ?q=.

Poziom 4 — higiena modułów i API

14. Bezlitośnie audytuj zainstalowane moduły

Każdy moduł to kod działający wewnątrz Twojego sklepu, a każdy nieużywany moduł to ryzyko bez zysku. Trzy zasady: usuń wszystko, czego aktywnie nie używasz (wyłączenie nie wystarczy — pliki PHP nadal mogą być osiągalne); nigdy nie uruchamiaj modułów nulled (pirackich), które regularnie zawierają backdoory; i aktualizuj wszystko, sprawdzając komunikaty bezpieczeństwa na stronie dewelopera. Przestarzałe moduły firm trzecich są najczęstszym wektorem włamań do PrestaShop po niezałatanym rdzeniu.

15. Zablokuj albo wyłącz Webservice API

Jeśli używasz Webservice API PrestaShop (Parametry zaawansowane → Webservice), nadaj każdemu kluczowi minimalny zestaw zasobów zamiast pełnego dostępu, usuń nieużywane klucze, wymagaj HTTPS i ograniczaj po IP tam, gdzie możesz. Jeśli z niego nie korzystasz, ustaw Włącz usługę webservice PrestaShop na Nie. Klucz API z nadmiernymi uprawnieniami to pełny eksport danych czekający, aż ktoś go uruchomi.

16. Usuń dane domyślne i przykładowe

Pozostałości produktów demonstracyjnych, przykładowe kategorie i domyślne strony CMS niczemu nie służą, a podpowiadają wiek i strukturę instalacji. Usuń je, gdy sklep jest już prawdziwy.

Poziom 5 — nadużycia na froncie i kontrola botów

17. Zatrzymaj spam w formularzach za pomocą reCAPTCHA

Formularze kontaktowe, rejestracja konta, opinie i zapisy do newslettera to drzwi, przez które boty wchodzą, aby zalać sklep śmieciami i szukać słabości. reCAPTCHA zatrzymuje automatyczny szum bez blokowania prawdziwych klientów — konfigurację i dostrojenie po preestashopowemu opisujemy w naszym poradniku reCAPTCHA dla PrestaShop.

18. Blokuj złe boty i nadużywających odwiedzających

Poza CAPTCHA warto filtrować ruch, który nie ma w Twoim sklepie nic do roboty — scrapery, skanery podatności i klientów uderzających w endpointy. Prawdziwe egzekwowanie reguł przeciw wrogim botom powinno odbywać się na WAF, w regułach serwerowych albo w dedykowanym module bezpieczeństwa, a nie w ustawieniach rdzenia PrestaShop; Parametry sklepu → Ruch & SEO pomaga tylko przy robots.txt i wskazówkach dla crawlerów, które grzeczne boty respektują, a skanery ignorują. Geolokalizacja może ograniczać całe kraje, ale też nie jest kontrolą przeciw skanerom. Głębszy zestaw narzędzi opisujemy w kontroli odwiedzających: blokowaniu złych botów i niechcianego ruchu. Jeśli chcesz radzić sobie z konkretnymi powracającymi sprawcami po IP — klientem, który stale składa fałszywe zamówienia, albo jednym adresem, który wciąż sonduje sklep — zobacz dodatkowe informacje o kliencie i bany IP.

19. Zabezpiecz hasłem to, co nie jest gotowe dla publiczności

Treści stagingowe, strony hurtowe, niewydana kolekcja — wszystko, co jest opublikowane, ale nie powinno jeszcze być indeksowane ani przeglądane, powinno stać za hasłem, zamiast polegać na nieoczywistym adresie URL. Podejścia dla PrestaShop opisujemy w ochronie hasłem w PrestaShop.

Poziom 6 — monitoring, reakcja i odzyskiwanie

20. Monitorowanie integralności plików

Najszybszy sposób wykrycia przejęcia to zauważyć moment, w którym zmienił się plik, który nie powinien się zmieniać. Monitorowanie integralności plików (FIM) tworzy odciski plików PrestaShop i modułów oraz alarmuje, gdy któryś zostanie nieoczekiwanie zmodyfikowany — dokładnie to dzieje się w chwili, gdy atakujący wstrzykuje kod do kontrolera albo szablonu płatności. To system wczesnego ostrzegania, który zamienia ciche naruszenie w naprawę tego samego dnia.

21. Obserwuj logi dostępu

Przeglądaj logi dostępu serwera pod kątem sygnałów: serie żądań z jednego IP, powtarzające się wejścia na logowanie administracyjne, żądania plików, które nie istnieją (sondowanie podatności), oraz nieoczekiwane POST-y. Jeśli hosting oferuje fail2ban, skieruj go na logi PrestaShop, aby powracający sprawcy byli blokowani automatycznie. Wiedza o tym, jak wygląda normalny ruch, pozwala zauważyć nienormalny.

22. Monitoring dostępności i certyfikatu

Darmowy monitoring, taki jak UptimeRobot, sprawdzający niedostępność, wygaśnięcie SSL i nagłe skoki czasu odpowiedzi, działa podwójnie: wyłapuje awarie i sygnalizuje drenaż zasobów, na przykład przez ładunek kopiący kryptowaluty albo zalew ruchu, zanim zauważą to klienci.

23. Automatyczne, testowane kopie zapasowe poza serwerem

Codziennie twórz kopię plików i bazy danych, trzymaj kopie w co najmniej dwóch miejscach (serwer plus chmura poza serwerem) i — to część, którą wszyscy pomijają — faktycznie testuj odtworzenie raz na kwartał. Kopia zapasowa, której nigdy nie odtworzono, to nadzieja, nie plan. Szyfruj kopie bazy danych trzymane poza serwerem (zawierają dane klientów) za pomocą GPG. Zachowuj na przykład 30 dni kopii dziennych i kilka miesięcy kopii tygodniowych; miejsce jest tanie, a czysty punkt przywracania stoi między Tobą a zaczynaniem od zera.

24. Napisz plan reagowania na incydenty, zanim będzie potrzebny

Gdy sklep zostaje przejęty, najgorszym momentem na ustalanie kolejnego kroku jest druga w nocy. Udokumentuj to wcześniej: do kogo dzwonić (hosting, operator płatności, specjalista bezpieczeństwa), jak przełączyć sklep w tryb konserwacji bez utraty zamówień w toku, gdzie znajduje się najnowsza czysta kopia, jak ją odtworzyć i co sprawdzić potem. Jeśli najgorsze już się wydarzyło, nasz poradnik krok po kroku reakcja na naruszenie danych przeprowadza przez całą sekwencję, łącznie z obowiązkami zgłoszeniowymi wynikającymi z GDPR.

Przypadek szczególny: sklep, którego nie możesz jeszcze zaktualizować

Powyższa lista zakłada, że możesz instalować poprawki. Wiele prawdziwych sklepów nie może — mocno dostosowany motyw, krytyczny moduł bez kompatybilnej wersji, migracja platformy planowana za sześć miesięcy. To nie znaczy, że jesteś bezbronny. Wirtualne łatki, reguły WAF na brzegu sieci i celowane utwardzanie mogą osłonić znaną podatność bez dotykania rdzenia, kupując czas na porządną aktualizację. Pełny plan działania dla sklepów uwięzionych na starej wersji znajdziesz w poradniku zaawansowane utwardzanie PrestaShop dla sklepów, których nie możesz jeszcze zaktualizować.

Gdzie pasują moduły — i gdzie nie pasują

Większość tej listy kosztuje tylko uwagę: ustawienia, które już masz w back office, przełączniki w panelu hostingowym, godzina z plikiem .htaccess. Wolelibyśmy, żebyś zrobił to, niż kupował cokolwiek. Moduł zasługuje na miejsce tam, gdzie ręczna praca jest żmudna albo niemożliwa — przede wszystkim 2FA i utwardzanie logowania oraz ciągłe monitorowanie integralności plików, które obserwuje każdą zmianę pliku za Ciebie, zamiast zmuszać Cię do przeglądania logów wzrokiem. Nasze moduły bezpieczeństwa na mypresta.rocks obejmują te warstwy, konfigurowane z back office bez edycji rdzenia, więc aktualizacja ich nie cofnie. Co z tego wynika? Płacisz za automatyzację kontroli, za którymi człowiek nie nadąży ręcznie — nie za zastąpienie darmowej higieny, która wykonuje większość pracy.

Uczciwe podsumowanie

Bezpieczeństwo w PrestaShop nie jest projektem, który się kończy; to standard, który trzeba utrzymywać. Dobra wiadomość jest taka, że ataki uderzające w Twój sklep są w większości proste i zautomatyzowane, więc podstawowe, nudne zabezpieczenia — aktualizacje, zmiana katalogu admina, wymuszenie HTTPS, silne hasła, 2FA, kopie zapasowe, które naprawdę przetestowano — zatrzymują przytłaczającą większość z nich. Przejdź tę listę od góry do dołu, korzystaj z głębszych poradników przy kolejnych zabezpieczeniach i ustaw w kalendarzu powtarzające się przypomnienie raz na kwartał, aby uruchomić ją ponownie. Włamania prawie nigdy nie dotyczą sklepów, które zrobiły nudne rzeczy; dotyczą tych, które miały je zrobić.

Szybka kontrola: wypisz każde konto back office jednym zapytaniem

Punkt 2 każe uporządkować listę pracowników i potwierdzić, że nikt po cichu nie utworzył konta, którego nie rozpoznajesz. Back office pokazuje to w sekcji Parametry zaawansowane → Zespół → Pracownicy, ale zapytanie SQL tylko do odczytu szybciej się przegląda i trudniej je oszukać przez zmieniony interfejs administracyjny. Uruchom je na swojej bazie danych (dostosuj prefiks ps_ do własnego) — tylko czyta dane, niczego nie zmienia:

-- Read-only: every back-office account, newest first.
-- Flag SuperAdmins (id_profile = 1) you don't recognise, and any
-- account whose date_add is recent but that nobody on your team created.
SELECT id_employee, email, id_profile, active, date_add, last_connection_date
FROM ps_employee
ORDER BY date_add DESC;

Dwa typy wierszy zasługują na drugie spojrzenie: każdy id_profile = 1 (SuperAdmin), którego się nie spodziewasz, oraz każde konto, którego date_add wpada w okres, w którym nie wdrażaliście nowych osób. Fałszywy SuperAdmin utworzony podczas przejęcia to jedna z pierwszych rzeczy, które atakujący zostawia, aby zachować drogę powrotu — i przetrwa czyszczenie malware, jeśli usuniesz tylko pliki. Jeśli najpierw chcesz zachować konto jako dowód, wyłącz je w back office zamiast usuwać.

Najczęściej zadawane pytania

Mam mały sklep i nie mam dewelopera. Ile z tego mogę realnie zrobić samodzielnie?

Większość Poziomu 1 i Poziomu 2 — zmiana nazwy folderu admina, silne hasła, wymuszenie HTTPS, włączenie 2FA, usunięcie zbędnych kont, zaostrzenie uprawnień — to zadania w back office albo panelu hostingowym, bez kodowania. Elementy serwerowe (uprawnienia plików, .htaccess, nagłówki) to miejsce, w którym rozsądnie poprosić o pomoc hosting albo dewelopera. Zacznij od wersji prostym językiem w naszym poradniku dla właścicieli sklepów i idź dalej od niego.

Czy potrzebuję modułu bezpieczeństwa, czy darmowe utwardzanie wystarczy?

Darmowe utwardzanie wykonuje większość pracy i warto zrobić je najpierw bez względu na wszystko. Moduł ma sens tylko przy dwóch zadaniach, które ręcznie są żmudne albo niemożliwe: 2FA wraz z utwardzeniem logowania oraz ciągłe monitorowanie integralności plików, które obserwuje każdą zmianę pliku zamiast przeglądania logów wzrokiem. Jeśli płacisz, płacisz za automatyzację tych zadań — nie za zastąpienie darmowych podstaw.

Czy darmowy plan Cloudflare wystarczy jako WAF?

Dla typowego sklepu blokuje sporo powszechnego sondowania i dodaje ochronę DDoS, więc warto go włączyć. Plan Free nie potrafi jednak dopasowywać reguł limitowania tempa do query stringów ani user-agentów, co ma znaczenie, jeśli ktoś aktywnie Cię atakuje — na przykład ograniczanie zalewu ?q= z wyszukiwania fasetowego wymaga Pro. Dokładnie pokazujemy, gdzie kończą się możliwości Free, w poradniku zaawansowane utwardzanie dla sklepów, których nie możesz jeszcze zaktualizować.

Jak często powinienem uruchamiać tę listę kontrolną?

Ustaw powtarzające się przypomnienie raz na kwartał — dwadzieścia minut na potwierdzenie, że PrestaShop i moduły są aktualne, 2FA działa u wszystkich, konta byłych pracowników zniknęły, a kopia zapasowa naprawdę się odtwarza. Bezpieczeństwo w PrestaShop nie jest projektem, który się kończy; to standard, który trzeba utrzymywać.

Mój sklep działa na wersji, której nie mogę teraz zaktualizować. Czy jestem po prostu odsłonięty?

Nie — ale przechodzisz z łatania na wirtualne łatanie: reguły WAF na brzegu sieci, zablokowanie originu, aby atakujący nie mogli go ominąć, oraz celowane poprawki dla konkretnych luk wskazanych przez logi i komunikaty bezpieczeństwa. Pełny plan działania dla sklepów uwięzionych na starej wersji znajdziesz w poradniku zaawansowane utwardzanie PrestaShop dla sklepów, których nie możesz jeszcze zaktualizować.

Czytaj dalej

• Zabezpieczanie sklepu PrestaShop: prosty poradnik dla właścicieli sklepów — ten sam zakres bez żargonu, dla nietechnicznych właścicieli.
• Anatomia ataku w stylu Magecart na sklep PrestaShop 1.7.x — przed czym te zabezpieczenia faktycznie chronią, od środka.
• Reakcja na naruszenie danych: co zrobić, gdy ktoś włamie się do sklepu — spokojny plan krok po kroku na pierwsze godziny.