Co znajdziesz w tym artykule?
Wprowadzenie do problemu / definicja
Bezpieczeństwo stron płatności w e-commerce nie ogranicza się już do ochrony serwerów, aplikacji backendowych i samej bramki płatniczej. Coraz większe znaczenie ma warstwa uruchamiana bezpośrednio w przeglądarce klienta, gdzie obok kodu sklepu działają także skrypty analityczne, tag managery, widgety wsparcia, biblioteki reklamowe i komponenty podmiotów trzecich.
To właśnie ten obszar stał się jednym z głównych celów ataków typu web skimming i kampanii określanych zbiorczo jako Magecart. Wraz z wymaganiami PCI DSS v4.0.1 organizacje muszą dziś nie tylko zabezpieczyć środowisko płatnicze, ale również wykazać kontrolę nad skryptami uruchamianymi na stronach płatności.
W skrócie
Nowe wymagania PCI DSS v4.0.1, zwłaszcza 6.4.3 oraz 11.6.1, rozszerzają obowiązki firm obsługujących płatności online. Obejmują one inwentaryzację skryptów, ich autoryzację, uzasadnienie biznesowe oraz mechanizmy potwierdzania integralności.
Zmiana ta jest bezpośrednio związana z rosnącym zagrożeniem ze strony złośliwego JavaScriptu dostarczanego do przeglądarki użytkownika. Samo zaufanie do dostawcy zewnętrznego lub jednorazowa kontrola kodu nie są już wystarczające, jeśli organizacja nie monitoruje zmian treści strony i nagłówków HTTP.
Kontekst / historia
Ataki web skimming od lat należą do najpoważniejszych zagrożeń dla sektora e-commerce. Ich mechanizm jest prosty: napastnik wstrzykuje lub podmienia kod JavaScript na stronie płatności, a następnie przechwytuje dane wpisywane przez użytkownika do formularza.
Szczególnie groźne są scenariusze supply chain, w których celem staje się zewnętrzny dostawca skryptu, a nie sam sklep. Tego typu incydenty były szeroko obserwowane w kampaniach Magecart i stały się jednym z powodów doprecyzowania wymagań PCI DSS dla środowisk e-commerce.
Jednym z najczęściej przywoływanych przykładów pozostaje incydent British Airways z 2018 roku. Pokazał on, że kompromitacja strony płatności może prowadzić nie tylko do wycieku danych, ale również do poważnych konsekwencji finansowych, regulacyjnych i reputacyjnych.
Dodatkowo wymagania dotyczące ochrony skryptów na stronach płatności stały się obowiązkowe od 1 kwietnia 2025 roku. Dla wielu organizacji oznaczało to konieczność wdrożenia nowych procesów monitoringu po stronie przeglądarki.
Analiza techniczna
Requirement 6.4.3 koncentruje się na skryptach wykonywanych na stronie płatności. Organizacja powinna utrzymywać pełną inwentaryzację takich zasobów, zapewniać autoryzację każdego skryptu, dokumentować biznesowe uzasadnienie jego obecności oraz potwierdzać integralność kodu.
Requirement 11.6.1 dotyczy wykrywania manipulacji zawartością strony płatności i nagłówkami HTTP odbieranymi przez przeglądarkę klienta. To istotne, ponieważ nowoczesny atak nie musi polegać na prostej podmianie statycznego pliku. Złośliwe funkcje mogą być dostarczane dynamicznie, wybiórczo lub za pośrednictwem zaufanego wcześniej zasobu.
W praktyce oznacza to, że tradycyjne kontrole oparte wyłącznie na przeglądzie kodu aplikacji, testach po stronie serwera czy kontroli konfiguracji przestają wystarczać. Jeśli legalny skrypt partnera zostanie przejęty lub zmieniony, adres zasobu może pozostać taki sam, podczas gdy jego zachowanie stanie się niebezpieczne.
Z perspektywy obrony technicznej oznacza to potrzebę monitorowania strony płatności z punktu widzenia rzeczywistej przeglądarki użytkownika. Kluczowe działania obejmują:
- mapowanie wszystkich zależności JavaScript i zasobów zewnętrznych,
- wykrywanie zmian w DOM oraz skryptów dołączanych dynamicznie,
- analizę połączeń wychodzących inicjowanych przez kod uruchamiany w przeglądarce,
- obserwację prób dostępu do pól formularzy zawierających dane płatnicze,
- kontrolę polityk bezpieczeństwa, takich jak CSP, oraz zmian w nagłówkach HTTP,
- alarmowanie o nieautoryzowanych modyfikacjach, dodatkach i usunięciach treści.
Warto też podkreślić, że stosowanie iframe płatniczego nie zawsze eliminuje ryzyko. Jeśli strona nadrzędna pozostaje podatna na ataki skryptowe, napastnik może wpłynąć na interakcję użytkownika lub przechwycić dane jeszcze przed ich przekazaniem do chronionego komponentu płatniczego.
Konsekwencje / ryzyko
Brak kontroli nad skryptami na stronie płatności wiąże się z bezpośrednim ryzykiem kradzieży danych kart, danych osobowych oraz informacji uwierzytelniających. To jednak tylko pierwszy poziom zagrożenia.
Drugim są konsekwencje związane ze zgodnością. Niewystarczająca kontrola nad skryptami może skutkować negatywnym wynikiem audytu PCI DSS, koniecznością wdrażania kosztownych działań naprawczych lub dodatkowymi wymaganiami dowodowymi podczas oceny.
Trzeci wymiar ryzyka ma charakter operacyjny. Ataki skryptowe bywają trudne do wykrycia, ponieważ wykorzystują już zaufane kanały dostarczania kodu. W środowiskach, gdzie warstwa marketingowa i analityczna zmienia się często, ręczne utrzymywanie pełnej kontroli staje się mało efektywne i podatne na błędy.
Rekomendacje
Firmy prowadzące sprzedaż online powinny traktować bezpieczeństwo strony płatności jako odrębny obszar kontroli technicznej i zgodności. W praktyce warto wdrożyć następujące działania:
- zbudować pełną inwentaryzację skryptów ładowanych na stronach płatności, także tych dołączanych pośrednio i dynamicznie,
- przypisać właściciela biznesowego do każdego skryptu oraz udokumentować proces jego autoryzacji,
- ograniczyć liczbę zewnętrznych zasobów do niezbędnego minimum,
- stosować mechanizmy wzmacniające integralność i ograniczające źródła wykonywania kodu,
- monitorować rzeczywiste zachowanie strony płatności w przeglądarce, a nie tylko stan repozytorium lub serwera,
- wdrożyć detekcję zmian w treści strony i nagłówkach HTTP zgodnie z wymaganiem 11.6.1,
- regularnie oceniać dostawców zewnętrznych pod kątem ryzyka supply chain,
- zweryfikować, czy model iframe lub outsourcingu faktycznie zmniejsza zakres obowiązków PCI,
- gromadzić materiał dowodowy na potrzeby audytu, w tym historię zmian, alerty i decyzje autoryzacyjne,
- włączyć monitoring strony płatności do procedur reagowania na incydenty.
Podsumowanie
Nowe wymagania PCI DSS potwierdzają istotną zmianę w podejściu do bezpieczeństwa e-commerce. Przeglądarka klienta stała się pełnoprawnym obszarem zarówno ataku, jak i kontroli zgodności.
Dla zespołów bezpieczeństwa oznacza to odejście od pasywnego zaufania do skryptów na rzecz ich aktywnej autoryzacji, obserwacji i walidacji. W praktyce bezpieczeństwo checkoutu nie sprowadza się już wyłącznie do ochrony formularza płatności, lecz do stałego udowadniania integralności całego ekosystemu skryptów, który go otacza.
Źródła
- The Hacker News — The Scripts on Your Checkout Page Are Now a PCI DSS Problem — https://thehackernews.com/2026/06/the-scripts-on-your-checkout-page-are.html
- PCI Security Standards Council — PCI DSS v4.0.1 Documentation and Guidance — https://www.pcisecuritystandards.org/
- SecurityMetrics — PCI DSS v4 Guidance Document: Requirements 6.4.3 and 11.6.1 — https://www.securitymetrics.com/learn/pci-dss-v4-guidance-document
- Sansec — Magecart Early Breach Detection Feed — https://sansec.io/guides/magecart-feed
- International Airlines Group — Theft of Customer Data at British Airways Update — https://www.iairgroup.com/press-releases/2019/theft-of-customer-data-at-british-airways-update/