PrestaShop publikuje oficjalne advisories bezpieczeństwa, a aktualizacje są zwykle kierowane przede wszystkim do najnowszej wspieranej wersji. W 2026 roku repozytorium projektu opublikowało m.in. krytyczny advisory dotyczący stored XSS. Dla starszego sklepu oznacza to jedno: bezpieczeństwo musi być procesem, nie jednorazową wtyczką.
7 warstw bezpieczeństwa sklepu PrestaShop
- Aktualny i wspierany core.
- Aktualne, zaufane moduły i motyw.
- Zabezpieczone konta administratorów.
- Poprawne uprawnienia plików i brak niepotrzebnych zapisów.
- Kopie zapasowe poza serwerem oraz test odtworzenia.
- Ochrona warstwy HTTP/WAF i poprawna konfiguracja hostingu.
- Monitoring logów, zmian plików i nietypowych zdarzeń.
Core, moduły i PHP: pierwsza linia obrony
Polityka bezpieczeństwa projektu PrestaShop wskazuje, że poprawki bezpieczeństwa są zazwyczaj kierowane do najnowszego wydania. Stary sklep może więc pozostawać na wersji, dla której część problemów nie będzie naprawiana w taki sam sposób jak w aktualnej gałęzi.
- Sprawdź wersję PrestaShop, PHP, bibliotek i serwera.
- Usuń nieużywane moduły zamiast tylko je wyłączać.
- Weryfikuj źródło modułu i historię aktualizacji.
- Nie instaluj „nulled” modułów ani motywów.
- Testuj aktualizacje na kopii sklepu, szczególnie przy integracjach ERP, płatnościach i kurierach.
Panel administracyjny i konta użytkowników
- Każda osoba powinna mieć własne konto – bez wspólnego loginu „admin”.
- Włącz MFA, jeśli stosowany panel/moduł lub warstwa SSO to umożliwia.
- Usuń konta byłych pracowników i firm zewnętrznych.
- Ogranicz role do niezbędnego minimum.
- Nie wystawiaj dodatkowych paneli diagnostycznych publicznie.
- Monitoruj logowania z nowych lokalizacji i nietypowe próby uwierzytelnienia.
Nietypowy URL może ograniczyć część automatycznych prób, ale nie zastępuje aktualizacji, kontroli dostępu i monitoringu.
Uprawnienia i integralność plików
Po infekcji często znajduję problem nie tylko w jednym pliku, ale w mechanizmie pozwalającym atakującemu wrócić: webshell, zmodyfikowany moduł, cron, konto administratora albo zbyt szerokie uprawnienia zapisu.
- Porównuj pliki core i modułów z zaufanymi paczkami.
- Szukaj świeżo zmienionych plików PHP w nietypowych katalogach.
- Sprawdź katalog uploads/img pod kątem wykonywalnego kodu.
- Zweryfikuj crony systemowe i aplikacyjne.
- Przejrzyj .htaccess, konfigurację serwera i pliki startowe PHP.
- Po naprawie zmień wszystkie klucze, hasła i dane dostępowe, które mogły zostać ujawnione.
Backup: kopia ma umożliwiać realne odtworzenie sklepu
| Element | Minimum | Dlaczego |
|---|---|---|
| Baza danych | Częste kopie + retencja. | Zamówienia i klienci zmieniają się stale. |
| Pliki | Core, moduły, motyw, obrazy i konfiguracja. | Sama baza nie odtworzy sklepu. |
| Lokalizacja | Kopia poza serwerem produkcyjnym. | Atak lub awaria serwera nie niszczy backupu. |
| Test restore | Cykliczne odtworzenie na środowisku testowym. | Wiesz, że kopia jest kompletna. |
WAF, hosting i logi serwera
Warstwa WAF może ograniczać część znanych wzorców ataków i botów, ale nie naprawi podatnego modułu. Hosting powinien dawać dostęp do logów HTTP/PHP oraz aktualnych wersji środowiska.
- Włącz HTTPS i HSTS po zweryfikowaniu konfiguracji.
- Ogranicz niepotrzebne metody i nagłówki, jeśli aplikacja ich nie używa.
- Ustaw limity uploadu i wykonywania tam, gdzie to możliwe.
- Analizuj skoki 404/500, nietypowe POST-y i próby dostępu do panelu.
- Oddziel środowisko testowe od produkcji i nie wystawiaj kopii bazy publicznie.
Monitoring: wykryj zmianę zanim klient ją zauważy
- Monitoring dostępności i odpowiedzi HTTP.
- Alerty o zmianach kluczowych plików.
- Kontrola nowych kont administratorów.
- Monitoring błędów PHP i wyjątków aplikacji.
- Kontrola certyfikatu SSL i miejsca na dysku.
- Okresowe skany zewnętrzne i ręczny przegląd logów.
Co zrobić, gdy sklep jest już zainfekowany?
- Ogranicz dostęp i zachowaj kopię dowodową przed czyszczeniem.
- Ustal przybliżony czas początku infekcji.
- Sprawdź pliki, bazę, logi, konta i crony.
- Zidentyfikuj wektor wejścia zamiast tylko usuwać widoczny malware.
- Wyczyść lub odtwórz ze znanej dobrej kopii.
- Zaktualizuj podatne komponenty.
- Zmień dane dostępowe i klucze.
- Sprawdź checkout, płatności, maile i SEO po naprawie.
- Monitoruj sklep przez kolejne dni pod kątem ponownego pojawienia się zmian.
Backup sprzed tygodnia może również zawierać malware. Najpierw ustal okno czasowe infekcji i sprawdź kopię.
Najczęstsze pytania
Czy antywirus na hostingu wystarczy?
Nie. Może pomóc wykrywać część złośliwych plików, ale bezpieczeństwo zależy też od aktualizacji, kont, modułów, konfiguracji i monitoringu.
Czy zmiana nazwy katalogu admin zabezpiecza sklep?
To drobna warstwa utrudniająca automatyczne próby, ale nie chroni przed podatnym modułem ani przejętym kontem.
Jak często robić backup sklepu?
Zależy od liczby zamówień. Baza sklepu o dużym ruchu może wymagać kopii wielokrotnie w ciągu dnia, a pliki rzadziej.
Czy po infekcji trzeba zmienić wszystkie hasła?
Należy założyć możliwość ujawnienia danych dostępowych i zmienić hasła oraz klucze, których atakujący mógł użyć.
Źródła i dokumentacja
Źródła sprawdzono 28 sierpnia 2026 r. Priorytet mają materiały oficjalne i dokumentacja pierwotna.
Historia aktualizacji
- publikacja poradnika, weryfikacja źródeł, linkowania wewnętrznego i danych strukturalnych.
Możemy zacząć od diagnozy i priorytetów zamiast od przypadkowego pakietu działań.
Diagnoza i plan działańhttps://pawlinaltd.pl/blog/jak-zabezpieczyc-sklep-prestashop-2026/