Model bezpieczeństwa sklepu internetowego powinien odpowiadać na trzy pytania: kto może zmieniać dane firmy, kto może uruchamiać kod w przeglądarce klienta i kto kontroluje drogę do płatności. To trzy różne rodzaje uprawnień. Nazwa funkcji ani bezpieczeństwo operatora płatności nie odpowiadają na wszystkie trzy.
Setka to nasz produkt. Kontrolujemy jej generowany kod, integracje i nawigację do płatności. Ścieżka, którą w udokumentowanych incydentach w Shopify przekierowywano klientów — skrypty i konfiguracja dostarczane przez aplikację — w architekturze Setki nie istnieje.
Jeśli twój sklep właśnie przekierowuje klientów w nieoczekiwane miejsce, zacznij od poradnika o incydentach w checkoucie Shopify. Stawia on zatrzymanie problemu i odzyskanie kontroli przed rozważaniami o architekturze.
Trzy rodzaje uprawnień w sklepie
Sprzedawca instaluje aplikację, żeby dodać opcje produktu. Potrzeba biznesowa jest wąska: klient ma wybrać grawer albo pakowanie na prezent. Uprawnienia techniczne integracji mogą jednak sięgać dalej niż ta widoczna funkcja.
| Uprawnienie | Co oznacza | Dobre pytanie sprzedawcy |
|---|---|---|
| Dane firmy | Odczyt lub zmiana rekordów, takich jak produkty, klienci i zamówienia | Które rekordy ta integracja może odczytać lub edytować? |
| Wykonywanie kodu w witrynie sklepu | Uruchamianie kodu, który zmienia stronę albo reaguje na działania klienta | Co jej kod może zmienić w przeglądarce klienta? |
| Nawigacja do płatności | Decyzja, dokąd akcja zakupu prowadzi klienta | Czy może zmienić cel albo dodać krok przed płatnością? |
Uprawnienia API aplikacji pomagają odpowiedzieć na pierwsze pytanie. Nie opisują w pełni drugiego i trzeciego. Dokumentacja zarządzania aplikacjami Shopify pokazuje obszary dostępu i ostatnią aktywność API. Osobno dokumentacja rozszerzeń motywu opisuje zasoby, w tym JavaScript, które integrują się ze sklepem.
To rozróżnienie zmienia sposób oceny integracji. Trzeba wziąć pod uwagę zarówno rekordy, do których sięga, jak i zachowanie, które może wprowadzić tam, gdzie klient robi zakupy.
Co wydarzyło się przed checkoutem
10 października 2026 roku programista Roman Zipp zbadał przekierowanie na fałszywy checkout w sklepie MechanicalKeyboards.com. Jego relacja z pierwszej ręki prowadzi do aplikacji Hulk Product Options. Zasób aplikacji pobierał konfigurację zawierającą własny JavaScript, który przechwytywał przejście do checkoutu i kierował klienta na podrobiony formularz płatności.
W zaobserwowanym przebiegu po wysłaniu fałszywego formularza klient trafiał do prawdziwego checkoutu. Atakujący nie musiał więc na stałe ukrywać prawdziwej płatności. Prawdziwy zakup mógł nastąpić zaraz po złośliwym kroku pośrednim.
Górna ścieżka streszcza udokumentowaną obserwację. Dolna mapa pokazuje, które części ścieżki zakupu są pod kontrolą Setki.
Sedno problemu to przesunięcie uprawnień: konfiguracja od dostawcy integracji stała się zachowaniem, które mogło przekierować ścieżkę zakupu. Badanie nie ustaliło, jak atakujący dostał się do systemu, więc ta ścieżka wyjaśnia jedno udokumentowane przekierowanie, a nie punkt wejścia każdego zgłoszonego incydentu.
Osobny komunikat Selleasy, zaktualizowany 16 października, potwierdza incydent z 13 października: wstrzyknięte skrypty i przekierowania na zewnętrzne strony phishingowe. To drugi, potwierdzony przez dostawcę przykład tego samego skutku, choć nie dowód na wspólny punkt wejścia.
Kiedy ustawienie staje się wykonywalnym kodem
Ustawienie może dostarczać dane: etykietę, identyfikator produktu, kolor. To kod aplikacji decyduje, jak tej wartości użyć. Ustawienie, które dostarcza JavaScript albo niezaufaną treść renderowaną jako wykonywalny kod HTML, niesie zupełnie inne uprawnienia.
Weźmy zmyślony przycisk listy życzeń. Jego etykieta powinna odpowiadać na pytanie: „Jaki tekst ma pokazać przycisk?”. Jeśli ta wartość może zamiast tego wprowadzić wykonywalne zachowanie, ustawienie robi znacznie więcej, niż tylko nazywa przycisk. Implementacja musi pilnować granicy między dostarczoną treścią a zachowaniem aplikacji.
Shopify w ramach kontroli bezpieczeństwa rozszerzeń motywu zajmuje się niezaufanymi wartościami renderowanymi bez bezpiecznego escapowania. Zaleca ich escapowanie i unikanie renderowania surowego HTML-a. To ilustruje granicę; nie jest ustaleniem przyczyny tych incydentów.
Dlatego „aplikacja dodaje tylko drobną funkcję” to za mało jako ocena. Cel funkcji i uprawnienia, które dostaje jej implementacja, to dwie osobne sprawy.
Znany adres skryptu to tylko część łańcucha
Kod, który przeglądarka ładuje jako pierwszy, może pobrać kolejny kod albo konfigurację z innego miejsca. Jeśli sprawdzisz tylko ten pierwszy plik, możesz przeoczyć zachowanie dodane później.
Udokumentowana ścieżka Hulk Product Options zaczynała się od zasobu serwowanego z CDN Shopify, który następnie pobierał konfigurację aplikacji. Nie znaczy to, że CDN Shopify został zhakowany. Znaczy to, że znajomy adres nic nie mówił o konfiguracji ładowanej po nim.
Historia plików motywu ma podobne ograniczenie. Rozszerzenia aplikacji dla motywu są zaprojektowane tak, by integrować się bez bezpośredniej edycji kodu motywu, a ich zasoby mogą zawierać kod uruchamiany w przeglądarce. Niezmieniony plik motywu nie dowodzi więc, że sklep na żywo działa tak samo jak wcześniej. To rozróżnienie opisuje dokumentacja rozszerzeń.
Wytyczne OWASP dotyczące JavaScriptu stron trzecich opisują szerszy problem: dostawca może zmienić to, co serwuje, już po tym, jak integracja przeszła pierwszy przegląd. Zaufanie dotyczy więc działającej integracji i dróg, którymi można ją zmienić, a nie tylko pliku, który sprzedawca widział przy instalacji.
Dlaczego chroniony checkout nie zabezpiecza drogi do niego
Shopify dokumentuje, że jego rozszerzenia interfejsu checkoutu działają w odizolowanym środowisku, bez dostępu do wrażliwych danych płatniczych ani do kodu HTML strony checkoutu. Te zabezpieczenia dotyczą tego środowiska.
Kod witryny sklepu działa wcześniej na ścieżce klienta. Jeśli akcja zakupu zostanie przechwycona, zanim klient dotrze do prawdziwego checkoutu, ochrona wewnątrz checkoutu nic nie mówi o stronie, na którą klienta wysłano zamiast tego.
To samo dotyczy wyboru operatora płatności. Operator chroni własny proces płatności; jego obecność nie gwarantuje bezpieczeństwa wszystkiego, o co inna strona prosi klienta wcześniej. Właściciel sklepu potrzebuje obrazu całej drogi, łącznie z tym, kto może wstawić dodatkowy krok albo podmienić cel.
Przy badaniu incydentu idź rzeczywistą ścieżką klienta. Przy wyborze platformy pytaj, kto ma nad tą ścieżką władzę.
Jak Setka kontroluje te granice
Setka pisze kontrolowany kod aplikacji i jest właścicielem całego stosu technologicznego oraz tego, jak działają w nim integracje. Generowanie witryny sklepu i obecne funkcje e-commerce działają wewnątrz platformy. Nie przekazujemy sprzedawcy wygenerowanego projektu z kodem motywu, który musiałby podłączać i utrzymywać.
Ustawienia aplikacji zewnętrznych nie mogą stać się dowolną, wykonywalną ścieżką integracji, która podmieni ścieżkę checkoutu w Setce. Kontrola nad drogą do płatności zostaje po stronie platformy. To granica wpisana w architekturę, a nie prośba, żeby sprzedawca sam wyłapywał każdą groźną zmianę, gdy ta dotrze już do klienta.
| Część systemu | Model Setki | Co to oznacza dla sprzedawcy |
|---|---|---|
| Wygenerowana witryna sklepu | Kontrolowany kod, którego właścicielem jest Setka | Kierujesz sklepem bez osobnego wdrożenia motywu do utrzymania |
| Obsługiwane integracje | Ich działanie i połączenie ze sklepem kontroluje Setka | Zewnętrzny dostawca aplikacji nie dostaje ścieżki skryptów i konfiguracji opisanej w ataku |
| Nawigacja do płatności | Kontrolowana w ramach architektury platformy | Przez tę powierzchnię integracji nie da się podmienić zamierzonej ścieżki płatności na fałszywy krok |
| Bieżące wdrożenie | Witryna sklepu i obecne funkcje e-commerce mają jednego właściciela | Zmiany pozostają w jednym modelu zgodności |
Checkout w Setce działa z kontem Stripe należącym do sprzedawcy. Stripe odpowiada za weryfikację konta, dostępność metod płatności i ustawienia wypłat; Setka łączy swój checkout z opłaconymi zamówieniami i obecnym procesem obsługi sprzedaży. Nasz poradnik o płatnościach wyjaśnia ten podział odpowiedzialności. Podłączenie Stripe to jedna część systemu; kontrola nad sklepem przed płatnością to druga.
Jasna granica to też jasna odpowiedzialność
Skoro Setka jest właścicielem stosu, to na Setce spoczywa zabezpieczanie i utrzymanie jej kodu, zależności, dostępów i integracji. Wyjaśnienie architektury powinno tę odpowiedzialność pokazywać wprost.
Setka zapisuje każdą wersję witryny sklepu, więc możesz wrócić do wcześniejszego wyglądu. Przywrócenie wyglądu to operacja na projekcie sklepu; nie przedstawiamy jej jako reakcji na incydent.
W praktyce oceniasz więc zarówno dozwolone drogi zmian, jak i to, kto za nie odpowiada. Dobre wyjaśnienie od dostawcy powinno pozwolić ci prześledzić mechanizm, bez polegania na ogólnikowej etykiecie „bezpieczne”.
Pytania przy wyborze dowolnej platformy sklepu
Zadaj je, zanim drobna funkcja stanie się dużą zależnością:
- Które ustawienia dostarczają dane, a które mogą wprowadzić wykonywalne zachowanie?
- Czy dostawca integracji może zdalnie zmienić to, co widzi i robi klient?
- Co powstrzymuje funkcję przed zmianą drogi do płatności poza jej zamierzonym celem?
- Jak dostarczane są zmiany i kto może zidentyfikować oraz wyłączyć problematyczny komponent?
- Za co odpowiada platforma, a jaka praca wdrożeniowa zostanie po stronie twojej firmy?
Dobra odpowiedź wskazuje granicę i jej właściciela. Te same pytania pomogą ocenić aplikację, zamówioną witrynę sklepu albo zintegrowaną platformę.
Jeśli już prowadzisz sklep na Shopify, skorzystaj z naszego poradnika audytu i usuwania aplikacji, żeby zbudować taki obraz swojego sklepu. Jeśli wybierasz platformę, porównaj model działania Setki z Shopify albo załóż sklep w Setce na bazie swojego katalogu i briefu.