Fałszywe płatności w sklepach Shopify. Jak cyberprzestępcy przechwytują dane kart i jak zabezpieczyć klientów?

Klient wybiera produkty, przechodzi do koszyka i klika przycisk finalizacji zamówienia. Otwiera się strona płatności przypominająca tę, którą zna z wcześniejszych zakupów. Wprowadza numer karty, datę jej ważności i kod zabezpieczający. Po chwili pojawia się komunikat o błędzie, a przeglądarka przenosi go do właściwego systemu płatności, gdzie kończy zakup.

Sprzedawca otrzymuje zamówienie, płatność zostaje prawidłowo zarejestrowana, a klient otrzymuje potwierdzenie zakupu. Wszystko wygląda tak, jak powinno.

Problem polega na tym, że pierwsza strona płatności należała do cyberprzestępców, którzy mogli już przechwycić dane karty klienta.

Nie jest to hipotetyczny scenariusz. W październiku 2026 roku ujawniono serię ataków na sklepy działające na Shopify. Przestępcy wykorzystali mechanizmy dostarczania kodu przez zewnętrzne aplikacje sklepowe, aby przekierowywać kupujących na fałszywe formularze płatnicze.

Incydenty potwierdzili między innymi dostawcy aplikacji Hulk Product Options, Selleasy oraz Swym Wishlist Plus. Wcześniej podobne przypadki wystąpiły również w aplikacjach Qikify.

Istotne jest to, że według opublikowanych ustaleń nie doszło do przełamania zabezpieczeń centralnego systemu płatności Shopify. Atak przeprowadzano na wcześniejszym etapie zakupów, kiedy klient nadal przebywał na stronie sklepu, a zewnętrzne skrypty mogły oddziaływać na przycisk przejścia do kasy.

Co wydarzyło się w sklepach Shopify w październiku 2026 roku?

10 października programista zajmujący się bezpieczeństwem aplikacji internetowych, Roman Zipp, zauważył nieoczekiwane zachowanie podczas zakupów w sklepie mechanicalkeyboards.com.

Po kliknięciu przycisku Checkout zamiast właściwej strony finalizacji zamówienia pojawił się formularz znajdujący się pod adresem biliing.top. Witryna przypominała kasę sklepową, ale znajdowała się poza infrastrukturą obsługującą legalną transakcję.

Analiza wykazała, że za przekierowanie odpowiadał kod JavaScript dostarczany za pośrednictwem aplikacji Hulk Product Options.

Co szczególnie ważne, sam plik skryptu pobierany z infrastruktury Shopify nie musiał być zmodyfikowany. Szkodliwy fragment znajdował się w danych konfiguracyjnych pobieranych przez aplikację z systemu jej dostawcy.

W kolejnych dniach zaczęły napływać informacje o podobnych incydentach dotyczących innych aplikacji.

Nie ustalono jednej, wspólnej przyczyny technicznej wszystkich incydentów. Poszczególni dostawcy opisali naruszenia swoich mechanizmów konfiguracji i dostępu. Nie ma podstaw, aby wszystkie przypadki automatycznie przypisywać tej samej grupie przestępczej.

Wymienienie nazwy aplikacji nie oznacza również, że każda jej instalacja została zainfekowana. Poszczególne ataki dotyczyły określonych sklepów i przedziałów czasowych, a dostawcy zgłaszali usunięcie wykrytego złośliwego kodu.

Jak działa przejęcie procesu płatności, czyli checkout hijacking?

Checkout hijacking polega na nieautoryzowanym przejęciu części procesu zakupowego. Przestępca nie musi kontrolować systemu rozliczającego płatności. Wystarczy, że potrafi zmienić działanie strony, z której klient rozpoczyna finalizowanie zamówienia.

W opisanych atakach wykorzystano fakt, że aplikacje rozszerzające funkcjonalność sklepów mogą uruchamiać JavaScript w przeglądarkach kupujących.

1. Złośliwy kod trafia do konfiguracji aplikacji

Wiele rozszerzeń pozwala sprzedawcy dodawać własne elementy HTML, komunikaty, skrypty lub ustawienia odpowiedzialne za zachowanie interfejsu.

Takie rozwiązania są przydatne przy rozbudowywaniu funkcjonalności sklepu, ale wymagają odpowiedniej kontroli. Jeżeli przestępca uzyska możliwość zmiany danych, które aplikacja następnie wykonuje jako kod JavaScript, może wpływać na zachowanie witryny.

W przypadku Hulk Product Options badacz ustalił, że skrypt aplikacji wysyłał zapytanie do interfejsu jej dostawcy, a odpowiedź zawierała około 22,7 KB nieautoryzowanego JavaScriptu w polu advanced_users.custom_js.

Oznacza to, że zagrożenia nie trzeba było umieszczać bezpośrednio w plikach motywu sklepu.

2. Przeglądarka klienta wykonuje niebezpieczne instrukcje

Po otwarciu strony sklepu legalny skrypt aplikacji pobierał dane konfiguracyjne, wśród których znajdował się kod wprowadzony przez napastnika.

Przeglądarka mogła następnie wykonać go w kontekście witryny sklepu.

Złośliwe instrukcje obserwowały działania użytkownika i reagowały na rozpoczęcie procesu płatności.

Do tego momentu kupujący mógł nie zauważyć żadnych nieprawidłowości. Produkty, ceny i zawartość koszyka nadal wyglądały normalnie.

3. Kliknięcie przycisku Checkout zostaje przechwycone

Kiedy klient wybiera przejście do kasy, prawidłowo działający sklep powinien otworzyć autoryzowaną stronę finalizacji zamówienia lub obsługiwany przez niego system płatności.

Złośliwy JavaScript mógł zatrzymać to działanie i zamiast niego uruchomić przekierowanie do zewnętrznej witryny.

W analizowanym przypadku napastnicy potrafili wykorzystywać informacje o koszyku, dzięki czemu fałszywy formularz mógł odpowiadać rzeczywistym zakupom klienta.

To zwiększało wiarygodność oszustwa. Użytkownik widział produkty i kwoty, których oczekiwał.

4. Fałszywa kasa zbiera dane płatnicze

Podrobiona strona mogła żądać danych identyfikacyjnych oraz informacji potrzebnych do płatności kartą.

Wśród nich znajdowały się:

• Imię i nazwisko właściciela karty.
• Numer karty płatniczej.
• Data ważności karty.
• Kod zabezpieczający CVV lub CVC.
• Informacje kontaktowe i rozliczeniowe klienta.

Roman Zipp podczas kontrolowanego testu wykazał, że dane wpisane do takiego formularza były przesyłane żądaniem HTTP do serwera pod adresem biliing.top.

W ten sposób potwierdzono działanie mechanizmu wyłudzania informacji.

5. Kupujący wraca do prawdziwej płatności

Po przesłaniu danych fałszywa strona mogła przekierować klienta do autentycznego checkoutu Shopify.

Użytkownik ponownie wprowadzał informacje lub wybierał właściwy sposób płatności, a zamówienie było finalizowane w zwykły sposób.

Sprzedawca mógł więc zobaczyć prawidłowo opłacone zamówienie, nie mając świadomości, że klient wcześniej trafił na stronę przestępców.

Prawidłowa realizacja zamówienia nie wyklucza wcześniejszego wyłudzenia danych karty.

Dlaczego wykrycie fałszywej strony płatności jest tak trudne?

Atak zaprojektowano w sposób ograniczający możliwość przypadkowego zauważenia problemu przez administratora sklepu.

Przekierowanie może następować tylko raz

W pierwszym szczegółowo zbadanym przypadku złośliwy skrypt zapisywał w pamięci sesji przeglądarki informację, że użytkownik został już skierowany na fałszywą stronę.

Wykorzystywano między innymi klucz:

__ctf_shim_handoff_done_v1

Po zapisaniu odpowiedniej wartości następna próba przejścia do kasy mogła przebiegać prawidłowo.

Administrator, który otrzymał zgłoszenie od klienta i próbował odtworzyć problem w tej samej sesji przeglądarki, mógł niczego nie zauważyć.

Dlatego testowanie checkoutu powinno obejmować nowe, niezależne sesje, a nie tylko wielokrotne odświeżanie tej samej karty.

W plikach motywu może nie być złośliwego kodu

Nieautoryzowany skrypt bywał przekazywany jako dane konfiguracyjne z serwera dostawcy aplikacji. Oryginalne pliki motywu oraz same rozszerzenia mogły pozostać niezmienione.

Porównanie plików motywu z kopią zapasową nie zawsze ujawni więc problem.

Analiza powinna obejmować również odpowiedzi API, skrypty wykonywane dynamicznie i ustawienia aplikacji.

Zamówienia w panelu administracyjnym nie muszą wyglądać podejrzanie

Przestępcy mogli doprowadzić do tego, że klient kończył płatność w autoryzowanym checkoutcie.

Sprzedaż była zatem księgowana prawidłowo, a panel administracyjny nie musiał pokazywać błędów ani nietypowych zamówień.

Analiza samych transakcji nie wystarczy do wykluczenia ataku.

Które aplikacje Shopify zostały powiązane z incydentami?

Potwierdzone komunikaty dostawców dotyczą trzech aplikacji zaangażowanych w październikową falę przekierowań.

Hulk Product Options

10 października wykryto nieautoryzowaną konfigurację rozszerzenia, która pozwalała na uruchamianie przekierowań do fałszywej kasy.

HulkApps poinformował, że usunął szkodliwy kod, wprowadził dodatkowe zabezpieczenia i zlecił niezależną ocenę bezpieczeństwa. Shopify tymczasowo wyłączył odpowiedni element rozszerzenia, a następnie przywrócił jego działanie.

Producent przekazał, że nie znalazł dowodów na analogiczne przekierowania pochodzące z innych swoich aplikacji.

Selleasy

13 października firma Logbase potwierdziła celowy atak na system obsługujący aplikację Selleasy.

Według opublikowanych informacji nieuprawniona osoba uzyskała dostęp do wewnętrznego narzędzia, które pozwalało modyfikować ustawienia aplikacji w części sklepów.

W efekcie do konfiguracji wprowadzono JavaScript przekierowujący klientów na stronę phishingową.

Dostawca poinformował o usunięciu szkodliwego kodu, dodatkowym zabezpieczeniu systemu i rozpoczęciu niezależnego dochodzenia. Nie stwierdzono wówczas dowodów naruszenia danych przechowywanych w backendzie ani bazie danych Selleasy.

Nie wyklucza to jednak możliwości wyłudzenia informacji od kupujących na zewnętrznej stronie przestępców.

Swym Wishlist Plus

14 października, pomiędzy godziną 10:06 a 11:56 UTC, nieuprawniona osoba dokonała zmian w konfiguracji aplikacji Swym Wishlist Plus.

W określonej grupie sklepów mogło to spowodować ładowanie kodu przekierowującego klientów do fałszywego checkoutu.

Producent rozpoczął wdrażanie działań naprawczych o 15:02 UTC i poinformował o ich zakończeniu o 16:32 UTC.

Swym oświadczył, że nie wykrył dowodów przejęcia kont sprzedawców ani danych przechowywanych we własnej infrastrukturze. Usunął zidentyfikowany skrypt oraz wymienił odpowiednie poświadczenia dostępowe.

Sprzedawcom, którzy zaobserwowali podejrzane przekierowania w tym okresie, zalecono kontakt z dostawcą.

Wcześniejszy incydent Qikify

Podobny mechanizm został wykorzystany już 22 lipca 2026 roku przeciwko aplikacjom Qikify Sticky Add to Cart i Qikify Mega Menu & Navigation.

W tym przypadku przestępcy umieszczali skrypty w konfigurowalnych polach HTML.

Qikify poinformował, że problem został usunięty tego samego dnia, a późniejsza kontrola bezpieczeństwa zakończyła się przywróceniem aplikacji do sklepu Shopify App Store.

Incydent ten nie stanowił części nowej październikowej infekcji, lecz pokazuje, że zagrożenie związane z wykonywaniem niekontrolowanego kodu z konfiguracji aplikacji występowało już wcześniej.

Jak sprawdzić, czy klienci Twojego sklepu byli przekierowywani do fałszywych płatności?

Najważniejszy jest test rzeczywistej ścieżki zakupowej, połączony z kontrolą aplikacji uruchamiających kod na stronie.

Krok 1. Otwórz sklep w nowej sesji prywatnej

1. Uruchom nowe okno prywatne przeglądarki.
2. Otwórz adres swojego sklepu internetowego.
3. Dodaj dowolny produkt do koszyka.
4. Kliknij przycisk Checkout lub Przejdź do kasy.
5. Sprawdź, pod jakim adresem otwiera się kolejna strona.
6. Powtórz test na innym urządzeniu lub w kolejnej nowej sesji prywatnej.

Adres powinien odpowiadać rzeczywistej konfiguracji płatności sklepu, uwzględniającej domenę sklepu, obsługiwany checkout Shopify i ewentualne autoryzowane usługi płatnicze.

Nie należy uznawać każdej zewnętrznej domeny za złośliwą. Niektórzy legalni operatorzy płatności również wykorzystują przekierowania. Kluczowe jest porównanie adresu z zatwierdzoną konfiguracją usług.

Jeżeli otwiera się nieznana witryna żądająca danych karty, przerwij test. Nie podawaj prawdziwych informacji płatniczych.

Krok 2. Zbadaj żądania sieciowe w przeglądarce

W przeglądarkach opartych na Chromium można użyć narzędzi deweloperskich.

1. Otwórz narzędzia deweloperskie i przejdź do zakładki Network.
2. Włącz opcję Preserve log, aby zachować historię po przekierowaniu.
3. Rozpocznij nową sesję testową z otwartymi narzędziami.
4. Przejdź od strony produktu do koszyka i finalizacji zamówienia.
5. Sprawdź, czy pojawiły się żądania do nieznanych domen lub nieautoryzowane przekierowania.
6. Zapisz istotne informacje o czasie, adresach i pochodzeniu podejrzanych żądań.

W przypadku przekierowania uruchamianego tylko raz szczególne znaczenie ma przeprowadzenie analizy podczas pierwszej próby przejścia do checkoutu.

Pliki HAR zawierające zarejestrowany ruch mogą obejmować pliki cookie, identyfikatory sesji i inne informacje poufne. Przed przekazaniem ich poza organizację trzeba usunąć lub odpowiednio zabezpieczyć takie dane.

Krok 3. Sprawdź aplikacje i ich osadzenia w motywie

W panelu administracyjnym Shopify otwórz sekcję zarządzania aplikacjami i kanałami sprzedaży.

Zidentyfikuj wszystkie rozszerzenia mogące wpływać na koszyk, interfejs sklepu, formularze i przechodzenie do płatności.

Następnie przejdź do edycji aktywnego motywu sklepu i sprawdź App embeds oraz bloki aplikacji.

Shopify umożliwia aplikacjom dodawanie takich elementów również wtedy, gdy nie są one widoczne dla kupującego jako osobne komponenty.

Zweryfikuj także funkcje dodawania własnego HTML i JavaScriptu w ustawieniach aplikacji.

Obecność takiej funkcji nie oznacza automatycznie luki bezpieczeństwa. Wymaga jednak upewnienia się, że dostęp do jej konfiguracji jest odpowiednio kontrolowany.

Krok 4. Skontroluj podejrzane domeny

W dochodzeniu Romana Zippa wymieniono między innymi następujące domeny wykorzystywane podczas prób wyłudzania danych:

• biliing[.]top
• checkout-confirm[.]top
• order-confirm[.]top
• account-confirm[.]top
• billing-confirm[.]top

W zgłoszeniach innych sprzedawców pojawił się również adres checkout-guard[.]top, jednak nie ustalono publicznie jego związku z konkretną aplikacją.

Podane adresy są wskaźnikami pomocnymi w poszukiwaniu śladów ataku, a nie pełną listą wykorzystywanej infrastruktury.

Brak tych domen nie dowodzi bezpieczeństwa sklepu. Podobnie sama końcówka .top nie stanowi dowodu złośliwego charakteru witryny.

Krok 5. Zbadaj nietypowe zgłoszenia klientów

Szczególną uwagę należy zwracać na informacje o:

• Dwukrotnym żądaniu danych karty podczas jednego zakupu.
• Nieoczekiwanym komunikacie o błędzie przed poprawną płatnością.
• Przejściu na nieznany adres internetowy.
• Wyglądzie checkoutu różniącym się od zwykle używanego.
• Nieoczekiwanych formularzach potwierdzania konta lub płatności.
• Podejrzanych transakcjach na karcie zgłoszonych po zakupie.

Takie sygnały powinny być analizowane nawet wtedy, gdy zamówienie zostało pomyślnie zrealizowane.

Co zrobić, gdy wykryjesz fałszywy checkout w swoim sklepie?

Aktywne przekierowanie klientów na stronę zbierającą informacje płatnicze wymaga natychmiastowej reakcji.

1. Zatrzymaj możliwość wyłudzania kolejnych danych

Jeżeli podejrzane zachowanie zostało potwierdzone, należy ograniczyć działanie zagrożonego elementu sklepu.

Może to oznaczać wyłączenie konkretnego osadzenia aplikacji, dezaktywację problematycznej integracji albo tymczasowe wstrzymanie zakupów, jeśli nie da się bezpiecznie odizolować przyczyny.

Trzeba uwzględnić zależności funkcjonalne. Wyłączenie aplikacji odpowiedzialnej za opcje produktów lub kalkulowanie ofert może zmienić sposób działania koszyka.

Priorytetem pozostaje niedopuszczenie do sytuacji, w której kupujący nadal trafiają na nieautoryzowaną stronę płatności.

2. Zabezpiecz informacje o incydencie

Zapisz:

• Dokładną datę i godzinę wykrycia.
• Adresy stron, pomiędzy którymi nastąpiło przekierowanie.
• Nazwy i wersje aktywnych aplikacji.
• Istotne żądania sieciowe i odpowiedzi serwerów.
• Otrzymane zgłoszenia klientów.
• Zrzuty ekranu lub inne dowody nieprawidłowego działania.
• Informacje o zmianach konfiguracji wykonanych podczas naprawy.

Nie utrwalaj rzeczywistych numerów kart ani kodów CVV w dokumentacji dochodzenia. Jeżeli przypadkowo pozyskano takie dane, trzeba zastosować właściwe procedury ochrony i obsługi incydentu.

3. Powiadom Shopify i dostawcę aplikacji

Przekaż techniczne informacje umożliwiające ustalenie, czy źródłem przekierowania jest konkretna integracja.

Zapytaj dostawcę o zakres incydentu, przedział czasowy, sposób usunięcia zagrożenia oraz ustalenia dotyczące wpływu na obsługiwane przez niego sklepy.

W przypadku potwierdzonej infekcji poproś o pisemne potwierdzenie zastosowanych działań naprawczych.

4. Sprawdź i zabezpiecz dostęp administracyjny

Zweryfikuj uprawnienia użytkowników, aktywne integracje oraz dostęp do kont zewnętrznych dostawców.

Jeśli istnieją przesłanki wskazujące na kompromitację poświadczeń, wymień odpowiednie hasła i unieważnij zagrożone tokeny.

Włącz uwierzytelnianie wieloskładnikowe dla wszystkich kont, które mają dostęp do administracji sklepem lub konfiguracji aplikacji.

5. Ustal, którzy klienci mogli być narażeni

Informacje o zamówieniach mogą pomóc określić grupę kupujących, ale nie powinny być jedyną podstawą oceny.

Skuteczny atak mógł dotknąć osoby, które porzuciły zakup po pojawieniu się fałszywego formularza. Z drugiej strony nie każda osoba odwiedzająca sklep w okresie incydentu musiała zostać przekierowana.

Ustalenie zakresu narażenia wymaga zestawienia informacji od dostawcy aplikacji, dostępnych danych technicznych, czasu działania złośliwego kodu i zgłoszeń klientów.

6. Ponownie przetestuj proces zakupu

Po usunięciu problemu przeprowadź testy na nowych sesjach przeglądarki i różnych urządzeniach.

Sprawdź także, czy usunięcie aplikacji nie pozostawiło osadzonych elementów lub nieoczekiwanych zmian w motywie.

Nie należy uznawać incydentu za zamknięty wyłącznie dlatego, że jeden test nie wykazał już przekierowania.

Co powinien zrobić klient, który wpisał dane karty na podejrzanej stronie?

Osoba, która podała numer karty, datę ważności i kod zabezpieczający na nieznanej stronie, powinna potraktować te informacje jako potencjalnie przejęte.

Najbezpieczniejszym działaniem jest niezwłoczny kontakt z bankiem lub wystawcą karty przez oficjalną aplikację albo znany numer kontaktowy.

Bank może zalecić zastrzeżenie karty i wydanie nowej, a także podjąć dodatkowe działania ograniczające możliwość nieautoryzowanych transakcji.

Należy również sprawdzić historię operacji i zgłaszać każdą nierozpoznaną płatność.

Jeżeli na fałszywej stronie podano hasło do konta klienta, powinno ono zostać zmienione z bezpiecznego urządzenia. Jeśli takie samo hasło było wykorzystywane gdzie indziej, również te konta wymagają zabezpieczenia.

Trzeba zachować ostrożność wobec późniejszych wiadomości podszywających się pod sklep lub operatora płatności.

Fakt, że rzeczywisty zakup ostatecznie zakończył się sukcesem, nie oznacza, że dane ujawnione wcześniej przestępcom są bezpieczne.

Czy sprzedawca musi zgłosić naruszenie ochrony danych osobowych?

Obowiązki wynikające z RODO zależą od rzeczywistego charakteru incydentu i ustalonego ryzyka dla osób, których dane dotyczą.

Jeżeli doszło do naruszenia ochrony danych osobowych, które może powodować ryzyko naruszenia praw lub wolności osób fizycznych, administrator danych powinien zgłosić je właściwemu organowi nadzorczemu bez zbędnej zwłoki, w miarę możliwości nie później niż w ciągu 72 godzin od stwierdzenia naruszenia.

Jeżeli ryzyko jest wysokie, może wystąpić dodatkowy obowiązek poinformowania osób dotkniętych zdarzeniem.

W przypadku polskich przedsiębiorców właściwym organem może być Prezes Urzędu Ochrony Danych Osobowych.

Osobno trzeba przeanalizować obowiązki wynikające z umów z operatorami płatności, bankami rozliczającymi i organizacjami kartowymi.

Nie wolno przyjmować, że brak dowodów wycieku danych z bazy Shopify oznacza automatycznie brak naruszenia. Dane klienta mogły zostać ujawnione na zewnętrznym formularzu, poza systemem sklepowym.

Jak Shopify zabezpieczył sklepy przed nieoczekiwanymi przekierowaniami?

20 października 2026 roku Shopify ogłosił wprowadzenie mechanizmu ostrzegającego klientów przed opuszczeniem witryny sklepu.

Pierwotnie rozwiązanie zakładało wyświetlanie komunikatu potwierdzającego przejście na zewnętrzną stronę.

23 października Shopify zmienił sposób działania funkcji. Zgodnie z opublikowanym komunikatem adresy rozpoznane jako złośliwe są blokowane, a przekierowania do stron ocenionych jako podejrzane wymagają potwierdzenia przez użytkownika. Pozostałe przejścia odbywają się bez dodatkowego komunikatu.

Jest to istotna warstwa ochrony, ale nie powinna zastępować kontroli aplikacji i skryptów uruchamianych w sklepie.

System automatycznej klasyfikacji adresów może nie rozpoznać każdej nowo utworzonej domeny wykorzystywanej przez przestępców.

Dlatego właściciel sklepu powinien nadal samodzielnie weryfikować rzeczywistą ścieżkę płatności.

Jak zmniejszyć ryzyko kolejnego ataku na checkout?

Bezpieczeństwo procesu zakupowego zależy nie tylko od zabezpieczeń platformy, ale również od liczby i uprawnień aplikacji, które działają na stronie sklepu.

Ogranicz liczbę niepotrzebnych aplikacji

Każde rozszerzenie może wprowadzać nowe skrypty, połączenia sieciowe i zależności od zewnętrznego dostawcy.

Nie oznacza to, że wszystkie aplikacje są niebezpieczne. Należy jednak regularnie usuwać lub wyłączać integracje, które nie są już wykorzystywane.

Przy audycie zwróć szczególną uwagę na aplikacje mogące modyfikować koszyk, przyciski zakupowe i kod wykonywany w przeglądarce.

Kontroluj konfigurację Custom JavaScript

Możliwość dodawania własnego JavaScriptu powinna być dostępna wyłącznie uprawnionym administratorom.

Dostawcy aplikacji powinni stosować odpowiednią kontrolę dostępu, walidację danych oraz mechanizmy ograniczające wykonywanie nieautoryzowanego kodu.

Właściciel sklepu powinien wiedzieć, które aplikacje dopuszczają takie ustawienia oraz czy ich konfiguracja była ostatnio zmieniana.

Monitoruj zmiany w skryptach i adresach zewnętrznych

Automatyczna kontrola może wykrywać pojawienie się nowych skryptów, zmianę ich zawartości i nieoczekiwane połączenia do zewnętrznych usług.

Warto objąć monitoringiem szczególnie strony koszyka oraz przyciski prowadzące do checkoutu.

Nie należy polegać wyłącznie na porównywaniu plików motywu. Jak pokazał październikowy atak, niebezpieczna zawartość może być pobierana dynamicznie jako odpowiedź z API aplikacji.

Regularnie testuj zakup od początku do końca

Test powinien obejmować świeżą sesję przeglądarki, dodanie produktu, otwarcie koszyka i przejście do autoryzowanego systemu płatności.

Warto wykonywać go po instalacji nowych aplikacji, zmianach w motywie i większych aktualizacjach integracji.

Dla sklepów o dużym natężeniu ruchu uzasadnione jest również monitorowanie zmian w ścieżce zakupowej, z uwzględnieniem mechanizmów, które mogą zachowywać się odmiennie podczas pierwszej i kolejnych wizyt.

Uwzględnij wymagania PCI DSS dotyczące skryptów

Standard PCI DSS 4.0.1 zawiera wymagania dotyczące zarządzania skryptami wykonywanymi na stronach płatności oraz wykrywania nieautoryzowanych zmian.

W szczególności wymagania 6.4.3 i 11.6.1 odnoszą się do kontroli skryptów i wykrywania naruszeń integralności stron związanych z płatnościami.

Dokładny zakres obowiązków zależy od architektury procesu płatności oraz modelu zgodności stosowanego przez sprzedawcę.

Wytyczne PCI Security Standards Council wskazują, że również strony mogące wpływać na bezpieczeństwo płatności wymagają odpowiedniego podejścia do ochrony przed atakami wykorzystującymi skrypty.

Najczęściej zadawane pytania o fałszywe płatności w Shopify

Czy hakerzy włamali się do systemu płatności Shopify?

Opublikowane ustalenia nie potwierdzają przełamania zabezpieczeń centralnego checkoutu Shopify. Przestępcy wykorzystywali nieautoryzowany kod dostarczany przez wybrane aplikacje zewnętrzne i przekierowywali klientów przed dotarciem do właściwej kasy.

Czy samo zainstalowanie Hulk Product Options, Selleasy lub Swym oznacza kradzież danych?

Nie. Potwierdzone incydenty dotyczyły określonych instalacji i okresów. Nie każdy sklep korzystający z wymienionych aplikacji musiał być zagrożony, a nie każdy klient odwiedzający sklep został przekierowany.

Czy fałszywy checkout może wyglądać identycznie jak prawdziwy?

Może bardzo dokładnie odtwarzać wygląd strony płatności, zawierać prawidłowe produkty i kwoty oraz wykorzystywać elementy graficzne podobne do autoryzowanego systemu. Dlatego należy kontrolować również adres witryny oraz przebieg przekierowań.

Dlaczego ponowny test płatności nie wykrywa problemu?

W analizowanym ataku skrypt potrafił zapamiętać w pamięci sesji przeglądarki, że przekierowanie zostało już wykonane. Kolejna próba mogła prowadzić bezpośrednio do prawidłowego checkoutu.

Czy sprzedawca zobaczy w Shopify informację o przechwyceniu karty?

Niekoniecznie. Dane były wpisywane na zewnętrznej stronie kontrolowanej przez napastnika. Zamówienie zakończone później w prawdziwym systemie mogło wyglądać całkowicie normalnie.

Czy wystarczy usunąć podejrzaną aplikację?

Wyłączenie źródła złośliwego kodu może zatrzymać przekierowania, ale potrzebne jest potwierdzenie, że nie pozostały inne nieautoryzowane skrypty lub integracje. Należy też ustalić, czy klienci mogli już ujawnić informacje płatnicze.

Czy Shopify blokuje wszystkie zewnętrzne strony płatności?

Nie. Według komunikatu z 23 października 2026 roku platforma blokuje adresy rozpoznane jako złośliwe oraz wymaga potwierdzenia dla podejrzanych przekierowań. Zwykłe, dozwolone przejścia na zewnętrzne witryny mogą odbywać się bez ostrzeżenia.

Co zrobić, jeśli klient zgłasza dwukrotne podawanie danych karty?

Należy potraktować zgłoszenie jako potencjalny incydent, zabezpieczyć istotne informacje, skontrolować działanie checkoutu w nowej sesji przeglądarki i niezwłocznie zgłosić problem Shopify oraz właściwym dostawcom aplikacji. Klient powinien skontaktować się z bankiem, jeżeli mógł ujawnić dane na nieautoryzowanej stronie.

Czy podobny mechanizm może wystąpić w WooCommerce lub Magento?

Tak. Nieautoryzowany JavaScript może wpływać na proces zakupowy również na innych platformach. Sposób uzyskania dostępu i wykrywania ataku jest zależny od architektury sklepu, rozszerzeń oraz konfiguracji serwera.

Bezpieczna transakcja zaczyna się jeszcze przed otwarciem strony płatności

Październikowe ataki na sklepy Shopify pokazują, że cyberprzestępcy nie muszą przejmować systemu rozliczającego płatności, aby wyłudzać informacje o kartach klientów.

Wystarczy możliwość wykonania odpowiedniego JavaScriptu na stronie sklepu i przechwycenia momentu, w którym kupujący przechodzi z koszyka do finalizacji zamówienia.

Największym problemem jest pozorna normalność całej transakcji. Klient może ostatecznie zapłacić w prawdziwym checkoutcie, a właściciel sklepu otrzymać prawidłowe zamówienie, mimo że wcześniej doszło do ujawnienia poufnych danych.

Dlatego kontrola bezpieczeństwa e-commerce powinna obejmować nie tylko samą platformę i operatora płatności, lecz także wszystkie aplikacje, skrypty i zewnętrzne usługi mające wpływ na proces zakupowy.

Ochrona klientów wymaga sprawdzania nie tylko tego, czy płatność działa, ale przede wszystkim tego, dokąd trafia kupujący po kliknięciu przycisku Checkout i jaki kod wykonuje w tym momencie jego przeglądarka.

Źródła

• Roman Zipp – Shopify shops hit with ongoing Checkout Hijack attack, analiza techniczna z 10 października 2026
• Logbase – Selleasy Security Incident Update, komunikat z października 2026
• Swym – Security Incident Update, 16 października 2026
• Shopify – New protection against unexpected redirects, 20 i 23 października 2026
• Qikify – Security Incident Notice, wcześniejszy incydent z lipca 2026
• PCI Security Standards Council – Payment Page Security and Preventing E-Skimming
• Urząd Ochrony Danych Osobowych – zasady zgłaszania naruszenia ochrony danych osobowych