Bezpieczeństwo sklepu internetowego - ranking sklepów internetowych pod względem zabezpieczeń

Dzisiaj poruszymy temat, który wraca do nas jak bumerang w rozmowach z klientami.

„Która platforma e-commerce jest najbezpieczniejsza?” albo „Czy Prestashop to na pewno dobry wybór pod względem bezpieczeństwa?”

No i wiecie co? Czas się z tym rozprawić raz na zawsze. Postanowiliśmy stworzyć luźny, ale konkretny ranking zabezpieczeń popularnych platform sklepowych. Bez lania wody i bez technicznego żargonu – wszystko w prostym języku, żeby każdy mógł zrozumieć, co tak naprawdę kryje się pod hasłem „bezpieczny sklep internetowy”.

Zaraz wejdziemy w szczegóły, ale zanim zaczniemy – jedna ważna rzecz: nie każda dziura bezpieczeństwa to wina samej platformy. Czasem winny jest nieaktualny dodatek, dziwna wtyczka z internetu albo hosting z epoki dinozaurów. Ale o tym za chwilę.

Dlatego w tym rankingu nie będziemy oceniać „czy platforma jest bezpieczna”, bo każda może być – pod warunkiem, że się o nią odpowiednio zadba. Zamiast tego skupimy się na konkretnych technologiach i rozwiązaniach, które są wbudowane w silnik danej platformy lub możliwe do ustawienia bez grzebania w kodzie.

Wymienię po kolei najważniejsze zabezpieczenia, wyjaśnię przed czym chronią i sprawdzę, czy mają je takie platformy jak:

• OpenCart
• WooCommerce (czyli WordPress + WooCommerce)
• PrestaShop
• Magento

Gotowi? To lecimy z pierwszym zabezpieczeniem.

 

Ochrona przed atakiem XSS – czyli żeby nikt nie grzebał nam w sklepie

Na pierwszy ogień bierzemy ochronę przed XSS, czyli atakami, które pozwalają komuś „wstrzyknąć” złośliwy kod (zazwyczaj JavaScript) do twojego sklepu. Wyobraź sobie, że klient wchodzi na twój sklep i... zamiast oglądać kosmetyki, jego przeglądarka wykonuje kod, który ktoś tam nielegalnie wkleił. Może to oznaczać np. kradzież danych logowania, przejęcie sesji albo podmianę treści.

No to sprawdzamy jak radzą sobie z tym trzy popularne silniki:

 

OpenCart 4 – bardzo dobrze!

OpenCart 4 korzysta z systemu szablonów Twig, który automatycznie koduje dane wyjściowe. Co to oznacza po ludzku? Jeśli ktoś próbuje „przemycić” niechciany kod do formularza albo komentarza, to system go zamienia na nieszkodliwy tekst. Super!

Dodatkowo, warto ustawić nagłówki CSP na serwerze – dzięki nim sklep sam mówi przeglądarce, skąd może ładować skrypty, a skąd nie. W praktyce to taka tarcza, która mówi „hej, nie wykonuj niczego, czego nie znam”.

Punkty: 4.  Domyślna ochrona + możliwość dalszego zabezpieczenia bez większego kombinowania. Na plus!

 

Magento – mocne zabezpieczenia, ale...

Magento ma naprawdę solidne wbudowane mechanizmy: każda dana od użytkownika jest sprawdzana i „czyszczona” zanim zostanie wyświetlona. Korzysta z funkcji takich jak escapeHtml, które robią robotę.

Ale jest jedno „ale” – dużo zależy od rozszerzeń. Jeżeli dodasz jakiś moduł z internetu, który nie stosuje się do zasad bezpieczeństwa Magento, to XSS może się przedostać mimo silnego rdzenia. Firma Adobe (właściciel Magento) robi wszystko, żeby to kontrolować, ale nie wszystko da się przewidzieć.

Punkty: 4. Dobre zabezpieczenia w teorii, ale trzeba uważać co się instaluje.

 

PrestaShop – tutaj trzeba uważać

PrestaShop nie ma aż tak solidnej ochrony „z pudełka”. Zabezpieczenia zależą głównie od tego, czy aktualizujesz system i czy używasz dodatkowych narzędzi (np. zapory WAF czy nagłówków bezpieczeństwa).

Niestety, historia pokazuje, że XSS to dość częsty problem w PrestaShop. Zdarzały się sytuacje, gdzie przez taką lukę można było nawet zdalnie przejąć kontrolę nad sklepem. Oczywiście te błędy są łatane, ale jeśli nie aktualizujesz – jesteś zagrożony.

Punkty: 3. Wymaga dodatkowej pracy i ciągłych aktualizacji. Dla kogoś nietechnicznego może być zbyt ryzykowne.

 

WooCommerce – zależy, co sobie zainstalujesz…

WooCommerce, jako rozszerzenie WordPressa, korzysta z jego mechanizmów zabezpieczających. A te są całkiem sensowne! Mamy funkcje takie jak esc_html(), esc_url() czy wp_kses(), które pilnują, żeby to co trafi na stronę, nie było przypadkiem złośliwym kodem JavaScript.

To trochę jak sprawdzanie zakupów przy kasie – wszystko, co trafia na stronę, jest przepuszczane przez filtry i niechciany kod powinien zostać odrzucony.

Ale… no właśnie: ALE.

Problem zaczyna się wtedy, gdy do sklepu doinstalujesz wtyczkę z niepewnego źródła albo nieaktualizowaną od dwóch lat. I to nie jest tylko teoria. Według raportu z 2024 roku, aż 96% problemów z bezpieczeństwem w WordPressie pochodziło właśnie z wtyczek. Tak, dobrze czytasz – prawie wszystko, co może się popsuć, psuje się przez dodatki.

Dlatego WooCommerce może być bezpieczny – ale ty musisz go takim uczynić. Regularne aktualizacje, przemyślany wybór wtyczek i motywów, dobre praktyki – bez tego ani rusz. Warto też ustawić nagłówki bezpieczeństwa (np. Content-Security-Policy), żeby zwiększyć ochronę przed XSS.

Punkty: 2. Można się zabezpieczyć, ale wymaga to świadomości i systematycznej opieki. Dla początkujących – łatwo coś przeoczyć.

 

Ochrona przed XSS (Cross-Site Scripting)

Platforma	Ocena XSS (0–5)	Uzasadnienie
Magento	4/5	Świetne mechanizmy (escapeHtml, $escaper), ale częste luki w rozszerzeniach i zewnętrznych modyfikacjach.
PrestaShop	3/5	Dobre praktyki, ale przeszłość pełna luk, podatność CVE-2024-34716, brak wbudowanego autoescape.
OpenCart 4	4/5	Autoescaping w Twig chroni bardzo dobrze, zwłaszcza jeśli nie kombinujemy z `
WooCommerce	2/5	WordPress daje świetne narzędzia (esc_*), ale 96% luk to wtyczki – praktycznie ryzykowne.

 

CSRF – czyli jak zabezpieczyć sklep, żeby nikt nie klikał za Ciebie

Dobra, wiemy już co to XSS. Teraz czas na CSRF – czyli inny typ ataku, który może przysporzyć właścicielom sklepów naprawdę sporych problemów. W skrócie: ktoś podszywa się pod zalogowanego użytkownika i wykonuje za niego akcję, której on sam nie zamierzał zrobić. Na przykład? Zmiana adresu dostawy, anulowanie zamówienia, a nawet – w przypadku panelu admina – usunięcie produktu albo zmiana hasła!

Zobaczmy, jak popularne platformy sobie z tym radzą:

 

Magento – solidna ochrona, ale trzeba uważać

Magento wykorzystuje coś, co nazywa się form keys – to takie unikalne „znaczki” dołączane do formularzy i zapytań. Serwer sprawdza, czy ten znacznik pasuje do aktualnej sesji – jeśli nie, to żądanie jest odrzucane. Prosto i skutecznie.

Ale uwaga: Magento technicznie pozwala pominąć tę ochronę, np. przy niestandardowych integracjach. I tutaj często pojawiają się problemy – ktoś tworzy wtyczkę, omija zabezpieczenia i CSRF wchodzi jak do siebie. Dlatego w Magento najwięcej zależy od... programisty.

Punkty: 4. Dobrze zabezpieczone, jeśli nikt nie grzebie na własną rękę.

 

PrestaShop – było słabo, jest lepiej, ale wciąż bywa problematycznie

Presta też korzysta z tokenów, ale – co tu dużo mówić – kiedyś miała z tym spore problemy. Luka z 2023 roku pozwalała wykorzystać token z poprzedniej sesji i dostać się do panelu admina. Serio. Zostało to naprawione, ale niesmak pozostał.

Nawet teraz użytkownicy skarżą się na błędy typu „CSRF token invalid”. Działa to trochę kapryśnie, zwłaszcza przy niektórych modułach i hostingach. I niestety – niektórzy właściciele sklepów wolą to wyłączyć niż rozwiązać.

Punkty: 3. Poprawnie działa, ale łatwo coś popsuć. Trzeba uważać.

 

OpenCart 4 – lekka ochrona, ale w dobrym kierunku

OpenCart korzysta z tokenów w URL-u (np. user_token) – czyli coś w stylu podpisu sesji. Stosowane to jest głównie w panelu admina. Działa i chroni przed podstawowymi atakami CSRF.

Ale: nie mamy jeszcze pełnej, konsekwentnej ochrony we wszystkich miejscach – np. po stronie klienta. Większość akcji administracyjnych jest zabezpieczona, ale przy mocno rozbudowanych sklepach warto samodzielnie wprowadzać dodatkowe warstwy zabezpieczeń.

Punkty: 4. Działa, ale jeszcze nie wszystko jest „na tip-top”. Do codziennego użycia – wystarczy.

 

WooCommerce – świetne narzędzia, ale wszystko zależy od Ciebie

WooCommerce bazuje na systemie nonces w WordPressie – to takie jednorazowe kody przypisane do akcji użytkownika. Co ważne – można je dodać do formularzy, przycisków, nawet do linków. Super sprawa.

Ale znowu – wtyczki. Cały ten świetny system ochrony jest tylko tak dobry, jak... osoby, które go używają. A że ponad 90% problemów z bezpieczeństwem WordPressa wynika z wtyczek, to nietrudno zgadnąć, gdzie jest słaby punkt.

Punkty: 3. Mechanizm świetny, ale bezpieczeństwo zależy od jakości dodatków i ich aktualizacji.

 

Ochrona przed CSRF (Cross-Site Request Forgery)

Platforma	Ocena CSRF (0–5)	Uzasadnienie
Magento	4/5	Form keys działają dobrze, ale można je obejść – i to robią niektóre dodatki.
PrestaShop	3/5	Są tokeny, ale system nie zawsze działa stabilnie. W przeszłości krytyczne luki.
OpenCart 4	4/5	Tokeny są, ale tylko w adminie. Frontend wymaga dodatkowej pracy programisty.
WooCommerce	4/5	Nonces to potężne narzędzie, ale ich skuteczność zależy od deweloperów – brak centralnego wymuszania.

 

Ochrona przed wstrzykiwaniem zapytań SQL (SQL Injection)

Z atakami SQL Injection jest trochę jak z włamaniem do sejfu przez szczelinę na listy. Ktoś z zewnątrz, jeśli ma spryt i lukę w systemie, może wstrzyknąć komendę (czyli kod SQL), która nie powinna się tam znaleźć – i w efekcie dostać się do bazy danych sklepu. A tam, wiadomo – dane klientów, zamówień, hasła, pełno wrażliwych rzeczy.

Zobaczmy, jak z tą ochroną radzą sobie najpopularniejsze platformy e-commerce:

 

Magento

Magento działa na wysokim poziomie, jeśli chodzi o ochronę przed SQL Injection. Korzysta z tzw. prepared statements, czyli bezpiecznego sposobu przekazywania danych do zapytań SQL. Zamiast „składać” zapytanie ręcznie, dane są wstrzykiwane osobno i nie mogą przypadkiem (albo celowo) zmienić jego znaczenia.

Dodatkowo, Magento ma swój własny system ORM (czyli taki tłumacz między PHP a bazą danych), który automatycznie zabezpiecza zapytania.

Ale... i tu ważna uwaga: bardzo dużo ataków SQLi w Magento pojawia się przez źle napisane dodatki lub niestandardowe modyfikacje. Dlatego, mimo solidnych fundamentów, trzeba uważać, co się instaluje.

Punkty (Magento): 4

 

PrestaShop

Tutaj też pojawiają się przygotowane zapytania – ale nie zawsze i nie wszędzie. PrestaShop ma historię poważnych luk SQL Injection – łącznie z takimi, które pozwalały kraść dane kart płatniczych.

Zdarzały się przypadki, że popularny moduł miał lukę tak poważną, że zdalny atakujący mógł przejąć kontrolę nad sklepem. A że PrestaShop bazuje mocno na zewnętrznych modułach – ryzyko tu jest spore.

Dlatego zalecamy nie tylko aktualizacje, ale i Web Application Firewall (WAF), który odsieje złośliwe żądania zanim dotrą do Twojego sklepu.

Punkty (PrestaShop): 3

 

OpenCart 4

OpenCart 4 też wspiera prepared statements, ale tu dużo zależy od programisty. Platforma nie zmusza do korzystania z ORM-u – co daje więcej swobody, ale i więcej ryzyka. W rękach dobrego developera: bezpieczna. W rękach początkującego: potencjalnie groźna.

Jasny plus: kod OpenCart 4 jest znacznie bardziej uporządkowany niż w poprzednich wersjach, a architektura została poprawiona. To sprzyja bezpieczeństwu – ale znowu, rozszerzenia firm trzecich to często słaby punkt.

Punkty (OpenCart 4): 3

 

WooCommerce

WooCommerce działa w oparciu o WordPressa, a tam ochronę zapewnia globalny obiekt $wpdb i metoda $wpdb->prepare(). Jeśli jest dobrze używana – daje solidną ochronę.

Problem w tym, że duża część dodatków i motywów z tej metody nie korzysta albo robi to źle. I tu znów wracamy do starego problemu: świetna platforma, ale ryzykowny ekosystem dodatków.

Warto też stosować WAF i dbać o audyty kodu – szczególnie przy sklepach z dużym ruchem.

Punkty (WooCommerce): 2

 

Podsumowanie punktowe – ochrona przed SQL Injection

Platforma	Ocena SQLi (0–5)	Uwagi
Magento	4/5	Dobry ORM, ale dodatki bywają niebezpieczne
PrestaShop	3/5	Historia krytycznych luk, poleganie na WAF
OpenCart 4	3/5	Dużo zależy od dewelopera, brak narzuconego ORM
WooCommerce	2/5	Bezpieczny rdzeń, ale ogromne ryzyko w dodatkach

 

Bezpieczne przechowywanie haseł – co siedzi pod maską Twojego sklepu?

No dobra – mówiliśmy o XSS, CSRF, SQL Injection, ale teraz czas na temat, który dotyczy każdego użytkownika sklepu: przechowywanie haseł.

I nie chodzi tu o to, gdzie klient zapisuje sobie hasło (na karteczce czy w przeglądarce), ale o to, co sklep robi z hasłem po stronie serwera.

Bo uwaga: jeśli sklep trzyma hasła „na czysto” w bazie, to nie mamy do czynienia ze sklepem. Mamy do czynienia z bombą z opóźnionym zapłonem.

Zobaczmy więc, które platformy szyfrują, które tylko udają, i gdzie właściciel sklepu może spać spokojnie.

 

Magento

Magento to wzór, jeśli chodzi o przechowywanie haseł. Używa bcrypt – czyli algorytmu, który działa wolno… i bardzo dobrze. Dlaczego? Bo im wolniejszy proces łamania hasła, tym trudniej je złamać nawet superkomputerowi.

Dodatkowo każde hasło ma swoją własną, losową sól – czyli dodatkowy „dodatek”, który sprawia, że nawet dwa identyczne hasła wyglądają w bazie zupełnie inaczej.

Do tego można wymusić odpowiednią długość hasła, cyfry, duże litery, znaki specjalne – wszystko, co trzeba.

Punkty (Magento): 5

 

PrestaShop

Tu mamy ciekawy przypadek. Starsze wersje PrestaShop (czytaj: wszystko przed 1.7) trzymały hasła zakodowane przy użyciu MD5 – czyli algorytmu, który dziś można złamać praktycznie na domowym laptopie z dobrą kartą graficzną.

Nowsze wersje prawdopodobnie przeszły na bcrypt, ale… nie ma jednoznacznej informacji, od której wersji, jak wygląda migracja starych haseł, i czy użytkownicy są bezpiecznie „przehaszowywani” po zalogowaniu.

To wszystko sprawia, że mimo poprawy – nadal trzeba uważać. Zwłaszcza jeśli ktoś migrował sklep z dawnych lat.

Punkty (PrestaShop): 3

 

OpenCart 4

Tutaj w końcu mamy postęp. W starszych wersjach (1.x, 2.x) hasła były kodowane przy użyciu SHA1, co dziś też nie daje spokoju. Ale OpenCart 4 (przynajmniej w wersji GitHubowej) korzysta już z password_hash() – czyli natywnej funkcji PHP, która domyślnie używa bcrypta.

Jeśli Twój sklep działa na czystej wersji OpenCart 4, wszystko wskazuje na to, że hasła są trzymane poprawnie. Ale… jeśli zaktualizowałeś się ze starszej wersji, upewnij się, że stare hasła są re-haszowane po logowaniu. W przeciwnym razie użytkownicy nadal będą mieć stare, słabe hasze.

Punkty (OpenCart 4): 4

 

WooCommerce

WooCommerce dziedziczy wszystko z WordPressa – a tam hasła były już od dawna dobrze zabezpieczone, dzięki mechanizmowi o nazwie PHPass.

Ale najlepsze info: WordPress 6.8 wprowadza nowszy, jeszcze lepszy system oparty na bcrypt + SHA-384, co jeszcze bardziej utrudnia złamanie haseł. Hasła są też automatycznie aktualizowane do nowego standardu przy pierwszym logowaniu po aktualizacji.

Świetna robota – i dowód na to, że cały ekosystem idzie w dobrym kierunku.

Punkty (WooCommerce): 5

 

Podsumowanie punktowe – bezpieczne hasła

Platforma	Ocena (0–5)	Uwagi
Magento	5/5	bcrypt + unikalna sól + polityka haseł
PrestaShop	3/5	Nowsze wersje OK, starsze niebezpieczne
OpenCart 4	4/5	Nowy standard, ale zależy od migracji
WooCommerce	5/5	Nowoczesne haszowanie, re-haszowanie starego formatu

 

Zmiana domyślnej ścieżki panelu administracyjnego – prosty sposób na zwiększenie bezpieczeństwa

Znasz to uczucie, gdy próbujesz otworzyć drzwi, a zamek jest nie tam, gdzie się go spodziewasz? Dokładnie tak działają niestandardowe ścieżki dostępu do panelu admina.

To tak zwana zasada security through obscurity. Nie zastąpi mocnych haseł czy ochrony przed brute force, ale robi ważną rzecz: utrudnia robotom znalezienie wejścia do zaplecza sklepu.

Sprawdźmy, jak wygląda to na różnych platformach.

 

Magento

Magento oferuje pełne wsparcie dla niestandardowego adresu zaplecza. Możesz zrezygnować ze standardowego /admin i ustawić coś mniej oczywistego, np. /panel-magazyn-47.

Co więcej, Magento może dodawać sekretne klucze do URL-i w panelu administracyjnym, co sprawia, że nawet jeśli ktoś zna ścieżkę, to i tak nie przejdzie dalej bez klucza. Mądrze!

Zmiana jest możliwa w panelu lub pliku env.php.

Punkty (Magento): 5

 

PrestaShop

PrestaShop też daje radę. Tutaj wystarczy… zmienić nazwę folderu admin na serwerze, np. na zarzadzanie987. Proste, szybkie i działa.

Platforma sama wykrywa nową nazwę i poprosi o zalogowanie przez nową ścieżkę. Nie ma żadnych czarów – ale efekt jest taki, że bot szukający /admin się odbije.

➡️ Trzeba tylko uważać, by przy aktualizacjach nie nadpisać folderu nazwą domyślną.

Punkty (PrestaShop): 4

 

OpenCart 4

Tutaj plus dla OpenCart za coś ekstra.

Po pierwsze – tak, możesz zmienić nazwę folderu admin (np. na centrum2025), a potem wystarczy poprawić odpowiednie ścieżki w config.php i admin/config.php. Czyli podobnie jak w PrestaShop – szybko, manualnie, ale skutecznie.

Ale jest coś jeszcze: OpenCart 4 domyślnie przenosi folder storage poza publiczny katalog domeny. To znaczy, że dane tymczasowe, backupy czy logi nie siedzą w katalogu widocznym dla wszystkich, tylko w bezpiecznym miejscu.

To bardzo mądry krok. Dzięki temu nawet jeśli ktoś „zajrzy” w strukturę katalogów, nie dostanie się do wrażliwych danych.

Punkty (OpenCart 4): 5

 

WooCommerce

WooCommerce działa w WordPressie, a tam dostęp do zaplecza zawsze odbywa się przez /wp-admin albo /wp-login.php. I nie da się tego zmienić bez pomocy dodatkowych wtyczek, jak np. WPS Hide Login.

Wtyczki te działają dobrze, ale są… wtyczkami – a więc mogą być nieaktualne, konfliktowe, a w skrajnym przypadku – zawierać własne podatności. W praktyce działa, ale wymaga większej czujności.

Bez wtyczki nie zmienisz ścieżki. Z wtyczką – możesz, ale rośnie ryzyko problemów.

Ocena (WooCommerce): 1

 

Podsumowanie – zmiana ścieżki i bezpieczeństwo katalogów

Platforma	Ocena (0–5)	Uwagi
Magento	5/5	Niestandardowa ścieżka + secret key
PrestaShop	4/5	Zmiana folderu działa, ale ręcznie
OpenCart 4	5/5	Zmiana ścieżki + przeniesiony storage
WooCommerce	1/5	Tylko z pomocą zewnętrznych wtyczek

 

Ochrona przed Atakami Brute Force – kto kogo przechytrzy?

Atak brute force to jak próba otwarcia zamka do drzwi milionem różnych kluczy. Jeśli system logowania nie ograniczy liczby prób – w końcu któryś z „kluczy” może pasować. Dlatego dobrze zaprojektowany sklep musi wiedzieć, kiedy powiedzieć „stop”.

 

Magento

Magento nie bawi się w półśrodki. To platforma enterprise, więc:

• ✅ Ma możliwość blokowania konta/IP po zbyt wielu błędnych logowaniach
• ✅ Obsługuje reCAPTCHA na stronie logowania
• ✅ Umożliwia 2FA bez kombinowania – to już standard
• ✅ Można ustawić czas życia sesji i hasła
• ✅ Można ograniczyć dostęp tylko z określonych IP

W skrócie: masz tu cały arsenał gotowy do wdrożenia. Potrzeba tylko… wdrożenia.

Punkty (Magento): 5

 

PrestaShop

PrestaShop daje radę, ale z drobnymi zastrzeżeniami:

• ✅ Obsługuje reCAPTCHA
• ✅ Można ograniczyć dostęp po IP (np. do admina)
• ⚠️ 2FA wymaga instalacji osobnych modułów (nie ma go w standardzie)
• ❓ Blokady logowania po wielu błędach? – zależy od konfiguracji i dodatków

To „można mieć wszystko”, ale nie „masz wszystko od razu”.

Punkty (PrestaShop): 4

 

OpenCart 4 

OpenCart od wersji 2.0 ma już wbudowany mechanizm limitowania prób logowania, który działa zarówno w panelu administracyjnym, jak i po stronie klienta.

• ✅ Limit prób logowania – domyślnie 10, można zmienić w panelu admina (System > Settings > Edit > Option > Login Attempts)

• ✅ Możliwość blokowania adresu IP po zbyt wielu błędnych logowaniach

• ✅ Możliwość ograniczenia dostępu do /admin przez .htaccess lub konfigurację serwera

• ⚠️ Brak 2FA i reCAPTCHA w standardzie – wymagają dodatkowych modułów

Oznacza to, że OpenCart 4 ma już solidną podstawę ochrony przed brute force – i to bez żadnych dodatków. Reszta to kwestia rozszerzeń i konfiguracji.

Punkty (OpenCart 4): 4

 

WooCommerce

WooCommerce dziedziczy wszystko po WordPressie. A to oznacza:

• ✅ Dostępność setek wtyczek bezpieczeństwa (Wordfence, Solid, Sucuri…)
• ✅ reCAPTCHA, limit prób logowania, 2FA, IP block – wszystko dostępne
• ⚠️ Ale… nic z tego nie jest wbudowane w sam WooCommerce

To jak otwarty plac budowy – możesz stworzyć twierdzę, ale musisz świadomie to zrobić.

Punkty (WooCommerce): 3

 

Podsumowanie – kto cię najlepiej chroni przed łamaniem hasła?

Platforma	Ocena (0–5)	Uwagi
Magento	5/5	Wszystko gotowe – CAPTCHA, 2FA, blokady IP
PrestaShop	4/5	Dobry poziom, ale 2FA tylko przez moduły
OpenCart 4	4/5	Podstawowa ochrona, reszta zależy od rozszerzeń
WooCommerce	3/5	Dostępna ochrona, ale wymaga aktywnej konfiguracji za pomocą wtyczek

 

Na froncie obrony przed brute force Magento nie ma sobie równych – oferuje kompleksową ochronę od razu. OpenCart wypada skromniej, ale można go rozszerzyć. WooCommerce i PrestaShop dają narzędzia, ale trzeba po nie sięgnąć samemu.

Separacja plików rozszerzeń i modułowość — co to w ogóle znaczy?

OK, zanim przejdziemy do technikaliów – wyjaśnijmy to po ludzku. Sklepy internetowe, jak każde oprogramowanie, z czasem się rozbudowują: dodajesz nową funkcję, integrację, płatność, slider czy cokolwiek innego. Ale jak to zrobić, żeby nie rozwalić sklepu przy aktualizacji albo nie stworzyć bałaganu w kodzie?

Modułowość to sposób budowy sklepu, który pozwala doinstalowywać nowe funkcje w formie „klocków” (czyli modułów), bez grzebania w podstawowym kodzie. Dzięki temu:

• łatwiej aktualizować sklep (bo nie modyfikujesz jego „serca”),
• łatwiej utrzymać porządek,
• mniejsze ryzyko, że jedna zmiana rozwali cały system.

No to teraz zobaczmy, jak z tym radzą sobie popularne platformy e-commerce:

 

Magento

Magento to taki kombajn w świecie e-commerce, i pod względem modułowości robi to prawie podręcznikowo. Każde rozszerzenie ma własny folder, np. app/code/MojSklep/NazwaModulu, co ułatwia organizację. Kod podzielony jest na warstwy – np. logika biznesowa jest oddzielona od widoków i bazy danych. To trochę jak rozdzielenie kuchni, jadalni i zmywaka – każdy robi swoje.

Plusy:

• Świetna separacja kodu,
• Bardzo dobra struktura,
• Łatwo izolować błędy.

Minus:

• To skomplikowany system – nie każdy developer ogarnie temat bez praktyki.

Punkty: 5

 

PrestaShop

PrestaShop też stawia na moduły – każdy moduł ma swoją strukturę i jest odseparowany. Od wersji 1.7 działa na Symfony (takim frameworku dla programistów) i szablonach Twig. To oznacza bardziej profesjonalną architekturę, lepszy podział logiki, i większe możliwości.

Plusy:

• Moduły nie grzebią w rdzeniu,
• Łatwiej aktualizować,
• Nowoczesna architektura (Symfony, Twig).

Minus:

• Starsze wersje były dużo słabsze pod tym względem.

Punkty: 4

 

OpenCart 4

OpenCart 4 zrobił spory skok jakościowy pod względem architektury i organizacji kodu. Po pierwsze – dalej trzyma się sprawdzonego wzorca MVCL (Model–View–Controller–Language), ale teraz wprowadza dodatkową separację plików systemowych i zewnętrznych.

Co to znaczy?
Twoje rozszerzenia, szablony, moduły czy integracje nie lądują już w tym samym katalogu co core systemu. OpenCart 4 wrzuca wszystkie zewnętrzne dodatki i szablony do katalogu extension/, co jest ogromnym plusem.

Dzięki temu:

• aktualizacja rdzenia nie nadpisze Twoich rozszerzeń,
• wiesz dokładnie, co pochodzi z systemu, a co zostało dodane ręcznie lub przez moduł,
• łatwiej zachować porządek i debugować.

Dodatkowo, mamy:

• silnik szablonów Twig, który poprawia bezpieczeństwo (np. automatyczne escapowanie danych),
• system zdarzeń (eventów), pozwalający modyfikować działanie sklepu bez grzebania w core,
• i oczywiście dalej obowiązuje podział admin/ vs catalog/ w każdej wtyczce.

To wszystko razem czyni OpenCart 4 najbardziej uporządkowaną wersją tej platformy w historii.

Punkty: 5

WooCommerce

WooCommerce działa jako wtyczka do WordPressa – a rozszerzenia to po prostu kolejne wtyczki. Każda z nich ma swój katalog, swój kod i styl. WordPress wymusza pewien porządek (foldery includes/, assets/, templates/) – ale nic nie blokuje twórcy przed zrobieniem bałaganu. To trochę wolna amerykanka.

Plusy:

• Elastyczność,
• Mnóstwo dodatków.

Minusy:

• Jakość wtyczek bywa bardzo różna,
• Mało narzuconej struktury – jak wtyczka jest słaba, to… jest słaba.

Punkty: 4

 

Zarządzanie Aktualizacjami i Podatnościami – kto dba o bezpieczeństwo po instalacji?

Jeśli myślisz, że bezpieczeństwo kończy się na dobrej instalacji sklepu, to niestety… nie. Jednym z najczęstszych powodów włamań są nieaktualne systemy. I nie chodzi tu tylko o sam „silnik sklepu” – ale też o szablony, dodatki, moduły i wtyczki. Wszystko, co ma kod, może mieć lukę. I jeśli taka luka jest już znana, a Ty nie zaktualizujesz – no cóż, cyberprzestępcy już wiedzą, gdzie szukać.

 

Magento

Magento (a właściwie Adobe Commerce) to prawdziwa „forteca” w tej dziedzinie.
Adobe aktywnie wspiera bezpieczeństwo – regularnie wypuszcza łatki bezpieczeństwa i prowadzi oficjalny program bug bounty na HackerOne. To oznacza, że hakerzy (ci dobrzy!) dostają nagrody za znajdowanie dziur.
Co więcej, Magento ma swoje narzędzie do skanowania sklepu – Commerce Security Scan – które pozwala właścicielowi wykrywać nieaktualne moduły, dziury konfiguracyjne i inne zagrożenia. Bardzo profesjonalne podejście.

Punkty: 5

 

PrestaShop

Presta też nie odstaje.
Aktualizacje wychodzą regularnie, a sam system ma dedykowaną politykę zgłaszania luk – można to zrobić mailem albo przez platformy bug bounty.
Na plus: reakcja społeczności i zespołu core jest zazwyczaj szybka. Na minus? Nadal zdarza się, że podatności są w oficjalnych modułach lub długo niełatanych dodatkach – więc tu trzeba być czujnym i samemu monitorować.

Punkty: 4

 

OpenCart 4

OpenCart jest trochę inny.
Tu nie znajdziesz oficjalnego bug bounty na HackerOne. Zgłoszenia luk trafiają na GitHub lub forum, a reakcje zależą od zaangażowania danego moderatora lub autora.
Ale! Wersja 4 wprowadziła kilka zabezpieczeń na poziomie core (m.in. separację katalogów, system wydarzeń, bezpieczniejsze logowanie), więc widać, że autorzy chcą iść w dobrą stronę.
Problem? Nie ma jednego kliknięcia "zaktualizuj wszystko" – często trzeba ręcznie nadpisywać pliki, a to odstrasza mniej technicznych właścicieli sklepów.

Punkty: 3

 

WooCommerce

WooCommerce korzysta z zaplecza WordPressa – a to oznacza częste aktualizacje i mnóstwo opcji.
Bezpieczeństwem zarządza Automattic (firma od WooCommerce i WordPressa), a program bug bounty działa na HackerOne.
Na plus: WordPress automatycznie aktualizuje wiele rzeczy (w tym samego siebie).
Na minus: wtyczki firm trzecich to tykająca bomba, jeśli nie są aktualizowane – więc tu znowu, trzeba być czujnym.
Dobrze skonfigurowany WooCommerce może być bezpieczny, ale trzeba go regularnie doglądać – jak ogrodu.

Punkty: 4

 

Czy mój sklep jest dziurawy? Porównanie podatności i rozszerzeń

Powiedzmy sobie szczerze – nawet najlepszy sklep internetowy może mieć dziury w zabezpieczeniach, jeśli ktoś nie dba o aktualizacje albo wrzuca byle jakie dodatki. Dlatego porównaliśmy cztery popularne platformy pod kątem:

• Ile wykryto luk bezpieczeństwa (tzw. CVE) w ostatnich 2 latach?
• Jak wygląda bezpieczeństwo dodatków i rozszerzeń, które często są źródłem problemów?

 

Liczby – czyli kto ma ile dziur?

Platforma	Rok	Wszystkie luki (CVE)	Luki XSS	Luki SQL	Luki CSRF
Magento	2023	1	0	0	0
	2024	(brak danych)	-	-	-
PrestaShop	2023	25	3	13	1
	2024	7	4	1	0
OpenCart	2023	brak danych	-	-	-
	2024	1	0	0	0
WooCommerce	2023–24	bardzo dużo, głównie przez wtyczki	dużo	dużo	dużo

 

Wniosek:

Najmniej problemów ma Magento – to jak pancerna limuzyna.

PrestaShop miał gorszy rok 2023, ale 2024 wygląda lepiej.

OpenCart trzyma się nieźle, ale danych jest mniej.

WooCommerce… no cóż – to potężna platforma, ale wtyczki ją czasem ciągną w dół.

 

A co z dodatkami i rozszerzeniami?

Prawie każdy sklep rozszerzamy o coś: nową funkcję, nowy wygląd, integrację z paczkomatem itd. Ale nie każdy dodatek jest bezpieczny. Zobaczmy jak różne platformy dbają o to, by do sklepu nie dostał się "zły kod". Niestety najczęściej rozszerzenia instalujemy na Woocommerce ponieważ jest najbardziej ubogi w funkcje.

 

Magento

Ma specjalny program testujący każde rozszerzenie przed publikacją w oficjalnym sklepie.
Testują kod, bezpieczeństwo, wydajność. Super podejście.

✅ Bezpiecznie, bo każda nowa wtyczka przechodzi kontrolę jakości.

 

PrestaShop

Ma oficjalny sklep z dodatkami, ale nie ma tak rygorystycznych testów jak Magento.
Niektóre firmy robią to porządnie i mają własne standardy, ale generalnie – trzeba patrzeć, od kogo kupujemy moduł.

⚠️ Bezpieczeństwo zależy od konkretnego autora modułu.

 

OpenCart

Tu też mamy oficjalny marketplace. Ale... nie ma centralnej kontroli bezpieczeństwa.
To znaczy, że możesz trafić na świetne rozszerzenia… albo takie, które mają luki jak ser szwajcarski .

❗ Uważnie wybieraj rozszerzenia, najlepiej znane i aktywnie rozwijane.

 

WooCommerce

WooCommerce korzysta z wtyczek WordPressa – a tego są dziesiątki tysięcy.
Część przechodzi kontrolę, ale wiele z nich jest robiona przez kogo popadnie.
Statystyki mówią jasno: 96% problemów z bezpieczeństwem WordPressa w 2024 roku to wina wtyczek.

To największy plus i minus WooCommerce – masz pełną wolność, ale też pełną odpowiedzialność.

 

Co z tego wynika?

• Jeśli chcesz sklep bezpieczny jak bank, Magento to Twój wybór.
• PrestaShop i OpenCart są ok, ale musisz samemu kontrolować, co instalujesz.
• WooCommerce daje ogromną elastyczność, ale wymaga czujności – bo łatwo dodać sobie wtyczkę z niespodzianką

 

Znane Wpadki Bezpieczeństwa – Czyli Kiedy Coś Poszło Źle

Bezpieczeństwo w teorii to jedno, ale jak wygląda w praktyce? Oto realne historie z ostatnich miesięcy i lat, które pokazują, że każdy system, nawet najlepiej zabezpieczony, może zostać złamany – jeśli nie działa się szybko i rozsądnie.

 

Magento – Ataki z wysokiego poziomu

Magento to „mercedes” wśród platform – profesjonalny, z solidnymi zabezpieczeniami. Ale… przez to przyciąga najbardziej zaawansowanych hakerów. Przykłady?

• Magecart – grupa hakerów, która od lat wstrzykuje złośliwe skrypty do sklepów Magento, by kraść dane kart płatniczych. Nawet drobna luka wystarczy, by dodać „niewidzialny podglądacz” do koszyka.
• CVE-2024-20720 – luka, przez którą atakujący mogli odpalić dowolne polecenie na Twoim serwerze, jakby siedzieli przy Twoim komputerze. Mega groźne.
• CosmicSting – krytyczna luka pozwalająca m.in. na kradzież plików konfiguracyjnych (np. kluczy szyfrujących). Adobe nie zareagowało od razu – łatki pojawiły się dopiero po kilku tygodniach, co pozwoliło hakerom „rozgościć się” w tysiącach sklepów.

Wniosek: Nawet najlepiej zabezpieczona platforma wymaga Twojej reakcji – nie możesz czekać z aktualizacjami.

 

PrestaShop – Moduły to pięta achillesowa

Tu najwięcej problemów pochodzi z zewnętrznych modułów:

• CVE-2024-36680 – luka w modułach do Facebooka, zainstalowanych w setkach sklepów. Pozwalała hakerowi „przejąć” bazę danych i wkleić kod kradnący dane kart.
• CVE-2024-26129 – mniej groźna, ale pokazuje, że nawet wyciek ścieżki serwera może naprowadzić hakera na kolejne ataki.

Wniosek: Sam PrestaShop może być bezpieczny, ale moduły mogą Cię wywrócić – nawet te najpopularniejsze. Zawsze aktualizuj.

 

OpenCart – Mało podatności, ale...

• CVE-2024-21519 – atakujący z kontem administratora mógł przesłać spreparowaną kopię zapasową i stworzyć plik PHP na serwerze (czyli np. tylne wejście).
• Jeśli katalog „storage” był dobrze skonfigurowany (poza webem), nic się nie stało. Ale jeśli nie – był problem.

Wniosek: OpenCart sam z siebie nie zawiera dużo błędów, ale musisz przestrzegać zaleceń bezpieczeństwa – np. przenieść foldery z danymi poza publiczny dostęp.

 

WooCommerce – Ofiara wtyczek

Najwięcej ataków dotyczy właśnie wtyczek firm trzecich. Oto dwa przykłady:

• Domniemany wyciek 4,4 mln rekordów – choć WooCommerce zaprzeczyło, dane mogły pochodzić z usług zewnętrznych. Pokazuje to, że nawet bez winy WooCommerce dane mogą wyciec, jeśli masz podłączone inne systemy.
• CVE-2025-47577 – luka we wtyczce do list życzeń. Pozwalała atakującemu wrzucić plik na Twój serwer bez logowania się. Jeśli wtyczka była zintegrowana z inną – exploity mogły działać natychmiast.

Wniosek: WooCommerce działa w ekosystemie WordPressa, gdzie każdy może zrobić swoją wtyczkę. A to oznacza ogromne ryzyko. Musisz kontrolować każdą wtyczkę jak pracownika.

 

Podsumowanie w Ludzkim Języku:

Platforma	Co się wydarzyło naprawdę?	Wniosek dla właściciela sklepu
Magento	Zaawansowane ataki grup Magecart, krytyczne luki z pełnym dostępem do serwera	Świetna platforma, ale nie można zasypiać – aktualizuj szybko i dodaj własne zabezpieczenia
PrestaShop	Popularne moduły (np. Facebook) z dziurami – można przez nie kraść dane płatnicze	Nie instaluj „bo jest darmowe/popularne” – sprawdzaj moduły i ich aktualizacje
OpenCart	Mało krytycznych incydentów, ale konfiguracja (np. katalog backup) może zaważyć na bezpieczeństwie	Zadbaj o konfigurację serwera i katalogów, bo rdzeń jest dość solidny
WooCommerce	Krytyczne luki we wtyczkach, domniemane wycieki danych, złożone zależności między rozszerzeniami	Minimalizuj liczbę wtyczek, aktualizuj je i sprawdzaj opinie oraz zależności

 

Ranking Bezpieczeństwa Sklepów Internetowych – Czas na Podsumowanie!

Czas podliczyć punkty i sprawdzić która platforma e-commerce jest bunkrem nie do sforsowania. 

Zabezpieczenie	Magento	Prestashop	Opencart	Woocommerce
Ochrona przed atakiem XSS – czyli żeby nikt nie grzebał nam w sklepie	4	3	4	2
CSRF – czyli jak zabezpieczyć sklep, żeby nikt nie klikał za Ciebie	4	3	4	3
Ochrona przed wstrzykiwaniem zapytań SQL (SQL Injection)	4	3	3	3
Bezpieczne przechowywanie haseł – co siedzi pod maską Twojego sklepu?	5	3	4	5
Zmiana domyślnej ścieżki panelu administracyjnego – prosty sposób na zwiększenie bezpieczeństwa	5	4	5	1
Ochrona przed Atakami Brute Force – kto kogo przechytrzy?	5	4	4	3
Separacja plików rozszerzeń i modułowość — co to w ogóle znaczy?	5	4	5	4
Zarządzanie Aktualizacjami i Podatnościami – kto dba o bezpieczeństwo po instalacji?	5	4	3	4
Razem	37	28	33	25

 

Testowaliśmy, analizowaliśmy, porównywaliśmy. Prześwietliliśmy zabezpieczenia czterech najpopularniejszych silników e-commerce jak rentgenem. Co wyszło? Zobaczmy, kto wyszedł z tego starcia z tarczą, a kto z ranami.

 

1. Magento – 37 pkt

Nie ma zaskoczenia – Magento zgarnęło złoto. To system zaprojektowany z myślą o dużych sklepach, dużym ruchu i dużym ryzyku. Ma wszystko: zabezpieczenia XSS, CSRF, SQLi, ochronę przed brute-force, reCAPTCHA, 2FA, systemowe separacje i formalny program bug bounty. Ale też wymaga wiedzy, ludzi i zasobów.

Dla kogo? Dla dużych graczy z zespołem IT i większym budżetem.

2. OpenCart 4 – 33 pkt

Niespodzianka? Tylko dla tych, którzy go nie znają. OpenCart 4 wprowadził ogromne zmiany w bezpieczeństwie – autoescaping dzięki Twigowi, przeniesiony katalog storage, limit logowań, rozdzielenie katalogów rozszerzeń, a wszystko to w systemie, który nadal pozostaje prosty, szybki i open-source.

Dla kogo? Dla średnich i małych biznesów, które chcą czegoś bezpiecznego, ale nie chcą mieć do wszystkiego 10 wtyczek.

 

3. PrestaShop – 28 pkt

Presta niby open source, ale brakuje jej trochę dyscypliny w kwestii bezpieczeństwa. Moduły to potencjalna bomba zegarowa. Dużo funkcji, ale też dużo podatności i historycznych incydentów. Plus za migrację do Symfony i Twig, ale to jeszcze nie to samo co Magento czy OpenCart.

Dla kogo? Dla tych, którzy już mają sklep na Preście i potrafią go dobrze prowadzić, ale start od zera? Hmmm…

 

4. WooCommerce – 25 pkt

WordPress + WooCommerce to jak związek z osobą z przeszłością – niby wszystko dobrze, ale wtyczki, wtyczki i jeszcze raz wtyczki. 96% luk to wtyczki. Możesz mieć tam zabezpieczenia klasy enterprise, ale wystarczy jedna zła wtyczka i pozamiatane.

Dla kogo? Dla blogera, influencera lub osoby, która zna WordPressa jak własną kieszeń i wie, czego nie instalować.

 

Wniosek?

Najlepszy balans między bezpieczeństwem, prostotą i rozszerzalnością? OpenCart 4.
Nie jest przesadzony, nie wymaga ogromnych zasobów, a i tak dostarcza bardzo solidny pakiet ochronny.

Opencart rządzi również w innym z naszych rankingów: Ranking platform e-commerce

Najwięcej punktów? Magento. Ale pamiętaj – to jak pancernik. Świetny, ale nie do każdej przystani.

Na końcu dnia – najważniejsze jest nie tylko co wybierzesz, ale jak tym zarządzasz. Nawet najlepszy system padnie, jeśli nie będziesz go aktualizować.

Chcesz mieć sklep naprawdę bezpieczny? Przestań wierzyć, że gotowiec z SaaS-a załatwi wszystko. Nawet darmowa platforma może być bezpieczna – jeśli ją dobrze ustawisz.