Skimmer na stronie kasy WooCommerce: jak sprawdzić przed Black Friday, czy ktoś nie kradnie kart Twoich klientów

Autor: Grzegorz Wojterzak. Aktualizacja: 9 listopada 2026. Czas czytania: około 13 minut.

W czerwcu 2026 roku firma CloudSEK opisała skimmer działający w sklepach WooCommerce z płatnościami Stripe (WooPayments). Jest groźny, bo niczego nie psuje: zamówienia spływają, pieniądze wpływają, klienci dostają paczki. Sklep dowiaduje się o nim tygodnie później, gdy banki powiążą oszustwa na kartach klientów z jednym miejscem zakupu.

Black Friday wypada w tym roku 27 listopada, a wtedy skimmer zbiera najwięcej. Poniżej: jak taki skrypt działa, jak sprawdzić kasę bez wiedzy programisty, jak ją zabezpieczyć i co zrobić, jeśli coś znajdziesz. Stan na początek listopada 2026.

Jak działa skimmer na stronie kasy

Skimmer to fragment kodu JavaScript, czyli programu wykonywanego w przeglądarce klienta. Nie siedzi w banku ani u operatora, tylko na Twojej stronie. Według CloudSEK opisany skrypt:

• czeka na pole płatności Stripe i dopiero wtedy się uruchamia,
• nakłada własny, łudząco podobny formularz karty. Prawdziwe pola Stripe są w ramce (iframe), czyli „okienku” operatora, do którego Twoja strona nie ma dostępu. Fałszywe pola są częścią Twojej strony, więc skrypt czyta wszystko, co klient wpisze,
• sprawdza numer karty tak jak prawdziwy formularz (sumą kontrolną Luhna), żeby błędy wyglądały wiarygodnie,
• wysyła numer, datę ważności, CVC i e-mail na serwer włamywacza w ruchu udającym statystyki,
• przepuszcza prawdziwą płatność, więc może działać miesiącami.

Skrypt to końcówka włamania. Wcześniej ktoś dostał się do strony przez nieaktualną wtyczkę, wykradzione hasło albo lukę i zostawił webshell, czyli ukryty plik, przez który steruje stroną. Dlatego usunięcie samego skryptu nie wystarcza: tylna furtka zostaje i skimmer wraca.

Czy to dotyczy Twojego sklepu

Opisany przypadek dotyczył WooPayments, ale CloudSEK zaznacza, że metoda działa przy każdym operatorze, bo celem jest strona sklepu. Są trzy sytuacje:

• Karta wpisywana na Twojej stronie w ramce operatora (np. Stripe, WooPayments). Skimmer ma najłatwiej, bo podmienia pola tam, gdzie klient się ich spodziewa.
• Przekierowanie do operatora, typowe przy BLIK-u i szybkich przelewach. Skimmer może dopisać fałszywe pola karty przed przekierowaniem, a część klientów je wypełni.
• Tylko płatność przy odbiorze lub przelew. Każde pole karty na kasie to alarm.

Zrób teraz zrzut swojej kasy i zapisz listę metod płatności: to wzorzec do porównań.

Test kasy w 10 minut

Wystarczy Chrome lub Edge na komputerze, bez dostępu do serwera. Nie wpisuj prawdziwej karty: działający skimmer przechwyci także Twoją.

1. Otwórz sklep w oknie prywatnym

   W oknie prywatnym (incognito) nie jesteś zalogowany i nie działają Twoje rozszerzenia. Część złośliwych skryptów nie pokazuje się administratorom, więc test z panelu nic nie powie. Powtórz go też na telefonie bez Wi-Fi, czyli z innego adresu IP.

2. Dodaj do koszyka tani produkt i przejdź do kasy

   Wybierz kolejno każdą metodę płatności i porównaj z wzorcem. Szukasz drugiego formularza karty, pól karty przy metodzie, która ich nie ma, albo prośby o ponowne wpisanie danych po „błędzie”.

3. Sprawdź, gdzie naprawdę są pola karty

   Kliknij prawym przyciskiem w pole numeru karty i wybierz „Zbadaj”. Otworzą się narzędzia deweloperskie z zaznaczonym kodem pola (zakładka Elements). Prawdziwe pole Stripe jest wewnątrz znacznika iframe, którego adres zaczyna się od https://js.stripe.com. Jeśli pole jest zwykłym elementem strony (input), a jego identyfikator kończy się na _sb, to wskaźnik opisany przez CloudSEK. U innych operatorów domena ramki jest inna, ale zasada ta sama: numer karty i CVC wpisuje się w ramce operatora, nie w zwykłym polu sklepu.

4. Przejrzyj połączenia w zakładce Sieć

   Przejdź do zakładki Network (Sieć) i odśwież stronę kasy. Wpisz w polu filtra -domain:twojsklep.pl (z minusem na początku): zostaną tylko połączenia do innych domen. Kasa naszego testowego sklepu pobiera 59 skryptów, wszystkie z domeny sklepu, więc po tym filtrze lista jest pusta. U Ciebie zostaną zwykle domeny operatora płatności, Google, może czatu lub piksela reklamowego. Każdą domenę, której nie przypiszesz do usługi, z której świadomie korzystasz, zapisz i sprawdź.

5. Wpisz w formularz dane, które nie są kartą

   Wpisz testowy adres i e-mail i obserwuj zakładkę Network. Połączenie z obcą domeną w chwili pisania, zwłaszcza z długim, zakodowanym ciągiem w adresie, to poważny sygnał. Test z numerem karty rób tylko na kopii sklepu w trybie testowym operatora, z kartą testową z jego dokumentacji: skimmer odrzuca numery niespełniające sumy kontrolnej, więc przypadkowe cyfry niczego nie uruchomią.

6. Zajrzyj do pamięci przeglądarki

   W zakładce Application (Aplikacja) otwórz Local Storage i adres sklepu. CloudSEK opisuje klucze udające piksel Facebooka (przedrostek w stylu fbpixel_) w sklepie bez piksela Meta oraz flagę ga-disable-G-…, która wyłącza Google Analytics dla wskazanego identyfikatora. Jeśli identyfikator jest Twój, zobaczysz to w raportach: zdarzeń zakupu w GA4 ubywa, zamówień w WooCommerce nie.

Gdzie skimmer chowa się na serwerze

Żeby usunąć skimmer, trzeba znaleźć wszystkie miejsca, z których się ładuje. CloudSEK wymienia pliki motywu, wtyczek i rdzenia, bazę danych (wp_options, treść stron, wtyczki do wstawiania kodu w nagłówku i stopce, widżety) oraz skrypt z obcego serwera. Listę miejsc w WordPressie, gdzie szukać wstrzykniętego skryptu, opisałem w poradniku o fałszywej CAPTCHA; dla skimmera jest taka sama.

Z dostępem SSH możesz użyć poleceń, które tylko odczytują dane. Pierwsze pokazuje pliki PHP i JS w motywach i wtyczkach zmienione w ostatnich 30 dniach, drugie szuka w bazie flagi wyłączającej Google Analytics, a ostatnie dwa pokazują wtyczki, których nie ma na zwykłej liście:

# pliki zmienione w ostatnich 30 dniach, najnowsze na końcu
find wp-content/themes wp-content/plugins wp-content/mu-plugins -type f \
  \( -name "*.js" -o -name "*.php" \) -mtime -30 \
  -printf "%TY-%Tm-%Td %TH:%TM  %p\n" | sort | tail -20

# flaga wyłączająca Google Analytics w bazie
wp db search "ga-disable-G" --all-tables-with-prefix --stats

# wtyczki must-use i drop-iny
wp plugin list --status=must-use
wp plugin list --status=dropin

Prawdziwy wynik pierwszego polecenia na testowej instalacji (koniec listy). Na dole dwie wtyczki must-use, ładowane zawsze, bez aktywacji; ostatnią podłożyliśmy do przykładu:

2026-10-16 09:22  wp-content/themes/twentytwentytwo/index.php
2026-10-16 09:28  wp-content/mu-plugins/wp-cache-helper.php
2026-11-02 11:23  wp-content/mu-plugins/hyper-engine-kit.php

Brak trafień w bazie wygląda tak: Success: Found 0 matches. Bez terminala to samo zrobisz w menedżerze plików hostingu (sortowanie po dacie) i w phpMyAdmin (wyszukiwanie w bazie). Zaciemniony skrypt nie zawiera czytelnych słów typu „card”, więc wyszukiwanie po tekście może go nie złapać. Pewniejsze jest porównanie z oryginałem: wp core verify-checksums i wp plugin verify-checksums --all.

Content Security Policy krok po kroku

Content Security Policy (CSP) to nagłówek, który serwer wysyła razem ze stroną. Mówi przeglądarce, skąd strona może ładować skrypty i dokąd może wysyłać dane. Jeśli skimmer spróbuje wysłać numer karty na nieznaną domenę, przeglądarka to zablokuje albo zgłosi. CloudSEK wymienia tu dwie dyrektywy: script-src (skąd wolno ładować skrypty) i connect-src (dokąd wolno się łączyć).

Źle ustawiona polityka zablokuje płatności, więc zaczyna się od trybu raportowania: nagłówek Content-Security-Policy-Report-Only według dokumentacji MDN niczego nie blokuje, tylko zgłasza naruszenia.

1. Spisz domeny, których kasa naprawdę potrzebuje

   Weź listę z testu w zakładce Sieć. Stripe publikuje wymagane wpisy w swoim przewodniku bezpieczeństwa (m.in. https://js.stripe.com dla skryptów i ramek, https://api.stripe.com dla połączeń); inni operatorzy podają je na prośbę.

2. Dodaj nagłówek w trybie raportowania, tylko na kasie

   Najprościej małą wtyczką must-use. Plik wp-content/mu-plugins/csp-kasa.php wysyła nagłówek tylko na stronie zamówienia. Sprawdziłem go na kopii testowego sklepu: nagłówek jest tylko na kasie. Domeny wpisz własne; te pasują do Stripe.

<?php
/* Plugin Name: CSP dla kasy (tryb raportowania) */
add_action( 'template_redirect', function () {
    if ( ! function_exists( 'is_checkout' ) || ! is_checkout() ) {
        return;
    }
    header( "Content-Security-Policy-Report-Only: "
        . "script-src 'self' 'unsafe-inline' "
        .   "https://js.stripe.com https://*.js.stripe.com; "
        . "connect-src 'self' https://api.stripe.com; "
        . "frame-src https://js.stripe.com https://*.js.stripe.com "
        .   "https://hooks.stripe.com; "
        . "img-src 'self' data:; "
        . "form-action 'self'" );
} );

3. Sprawdź, czy nagłówek działa

   W terminalu: curl -sI https://twojsklep.pl/zamowienie/ | grep -i content-security (adres kasy wpisz swój). Bez terminala: w zakładce Network kliknij pierwszy wiersz i sprawdź nagłówki odpowiedzi.

4. Obserwuj naruszenia przez tydzień lub dwa

   Lista domen w przykładzie dotyczy Stripe. WooPayments i polscy operatorzy, np. PayU czy Przelewy24, korzystają z innych domen, więc u nich lista będzie dłuższa. Tryb raportowania pokaże, czego brakuje. Przejdź kasę kilka razy, każdą metodą płatności, i otwórz zakładkę Console (Konsola). Chrome wypisuje tam każde naruszenie z dopiskiem [Report Only], np. [Report Only] Refused to connect to '…' because it violates the following Content Security Policy directive: "connect-src 'self'". Każde takie zdarzenie to domena do dopisania (np. Google Analytics) albo coś, czego na kasie być nie powinno. Raporty od wszystkich klientów wymagają adresu, który je zbiera: dyrektywy report-to z nagłówkiem Reporting-Endpoints (starsza, wycofywana forma to report-uri). To zadanie dla programisty.

5. Przełącz na tryb blokujący

   Gdy przez kilka dni nie ma uzasadnionych naruszeń, zmień nazwę nagłówka na Content-Security-Policy. Przeglądarka zacznie blokować połączenia spoza listy. Zrób testowy zakup każdą metodą płatności; usunięcie pliku cofa zmianę.

Pozostałe zabezpieczenia kasy

Jest też wymiar formalny. Od wiosny 2025 roku sklep, który potwierdza zgodność ze standardem kart PCI DSS uproszczonym kwestionariuszem SAQ A (typowym przy płatności w ramce lub z przekierowaniem), musi potwierdzić, że jego strona nie jest podatna na ataki skryptów. Według PCI SSC można to zrobić własnymi zabezpieczeniami, jak wyżej, albo na podstawie potwierdzenia od operatora, że jego formularz ma takie zabezpieczenia. Co to znaczy w Twojej umowie, zapytaj operatora.

Przed sezonem przejdź też listę kontrolną na Black Friday. Lawina nieudanych zamówień to inny atak: card testing.

Co zrobić po wykryciu skimmera

1. Zatrzymaj zbieranie danych

   Wyłącz płatności kartą albo kasę, a jeśli nie wiesz, gdzie siedzi skrypt, włącz tryb konserwacji sklepu z kodem 503. Nie usuwaj jeszcze niczego.

2. Zabezpiecz dowody

   Kopia plików i bazy w obecnym stanie oraz logi serwera pozwolą ustalić, kiedy skimmer się pojawił i których zamówień dotyczy.

3. Usuń wszystkie miejsca infekcji naraz

   Skrypt, jego ładowarkę w plikach lub bazie, webshell i obce konta. Procedurę opisuje usuwanie wirusa z WordPressa, a gdy skrypt wraca, poradnik wirus wraca po wyczyszczeniu strony.

4. Zmień hasła i klucze

   Hosting, FTP, SSH, baza, administratorzy, klucze bezpieczeństwa (salt) w wp-config.php, klucze API operatora płatności i innych usług.

5. Powiadom operatora płatności

   CloudSEK zaleca zgłoszenie do acquirera, czyli instytucji rozliczającej płatności kartami (dla małego sklepu zwykle operator płatności lub jego partner), i wypełnienie obowiązków z PCI DSS. Operator powie, czego oczekuje, np. raportu z incydentu.

6. Oceń obowiązki wynikające z RODO

   Dane karty razem z imieniem i e-mailem klienta to dane osobowe. Art. 33 RODO wymaga zgłoszenia naruszenia Prezesowi UODO w ciągu 72 godzin od jego stwierdzenia, chyba że ryzyko dla klientów jest mało prawdopodobne. Przy wysokim ryzyku trzeba też bez zbędnej zwłoki zawiadomić klientów (art. 34), a każde naruszenie udokumentować. Formularz jest na uodo.gov.pl. Decyzję podejmij z prawnikiem lub inspektorem ochrony danych.

Kiedy nie robić tego samemu

Test kasy zrobisz sam. Pomoc przyda się, gdy:

• test pokazał obce pola lub połączenia, a nie wiesz, skąd się ładują,
• skrypt wraca po usunięciu,
• trzeba ustalić z logów okres działania skimmera i listę zamówień dla operatora i UODO,
• chcesz wdrożyć CSP bez ryzyka zablokowania płatności w szczycie sezonu,
• nie masz pewności, czy włamanie skończyło się na skimmerze (zobacz jak sprawdzić, czy strona została zhakowana).

Najczęstsze pytania