Bezpieczeństwo sklepu internetowego — co testować przed sezonem sprzedażowym

Przed sezonem sprzedażowym testuj w pierwszej kolejności ścieżkę płatniczą, logowanie i kontrolę dostępu do zamówień, a dopiero potem resztę sklepu. Taka kolejność chroni pieniądze i dane klientów tam, gdzie ryzyko jest największe, i zostawia czas na poprawki oraz retest, zanim zespół zamrozi zmiany na czas szczytu sprzedaży.

Stan prawny na dzień 7 września 2026.

Od czego zacząć przegląd bezpieczeństwa sklepu przed sezonem

Zacznij od dwóch obszarów: ścieżki płatniczej i uwierzytelniania. Tylko tam pojedynczy błąd natychmiast zamienia się w utratę pieniędzy albo w naruszenie ochrony danych osobowych. Reszta sklepu, czyli katalog produktów, blog, newsletter i wyszukiwarka, też jest ważna. Rzadko jednak daje atakującemu bezpośredni dostęp do transakcji lub konta klienta.

Kryterium priorytetyzacji jest proste: najpierw to, co dotyka płatności, danych logowania i cudzych zamówień. W praktyce oznacza to koszyk, checkout, integrację z bramką płatniczą, rejestrację i logowanie, reset hasła, zarządzanie sesją oraz panel administracyjny. Dopiero po tych obszarach przechodzimy do funkcji marketingowych i treściowych.

Ta kolejność ma też uzasadnienie regulacyjne. Artykuł 32 RODO nakłada obowiązek doboru środków odpowiednich do ryzyka i regularnego testowania ich skuteczności. Ryzyko jest najwyższe tam, gdzie przetwarzane są dane adresowe, kontaktowe i transakcyjne klientów.

Rozdziel na starcie dwa różne działania. Skan podatności powie, jakie znane błędy ma dana wersja oprogramowania. Test penetracyjny sprawdzi, czy da się je połączyć w realny scenariusz nadużycia, na przykład kupić towar za złą cenę albo zobaczyć zamówienie innego klienta. Różnicę opisaliśmy szerzej we wpisie o tym, czym różni się skanowanie podatności od testu penetracyjnego.

Dlaczego skrypty firm trzecich w checkoucie wymagają osobnej kontroli

Skrypty firm trzecich w checkoucie wymagają osobnej kontroli, bo wykonują się w przeglądarce klienta na tej samej stronie, na której wpisuje on dane karty. Ich treści sklep zwykle nie kontroluje. Wystarczy, że dostawca tagu analitycznego, widżetu czatu albo skryptu remarketingowego zostanie przejęty, by na stronę płatności trafił kod zbierający dane formularza.

Na ten sam obszar wskazują dwa niezależne źródła. OWASP w edycji Top 10:2025 wyodrębnił nową kategorię A03:2025 Software Supply Chain Failures, obejmującą ryzyka wynikające z komponentów, zależności i kodu dostarczanego przez podmioty trzecie. Niezależnie od tego PCI Security Standards Council opublikował 10 marca 2025 dokument „Payment Page Security and Preventing E-Skimming – Guidance for PCI DSS Requirements 6.4.3 and 11.6.1”. Opisuje on trzy oczekiwania wobec skryptów strony płatności: autoryzację każdego skryptu, potwierdzenie jego integralności oraz monitorowanie prób manipulacji.

Zbieżność jest istotna, bo pochodzi z dwóch różnych światów: jedno źródło patrzy na klasy podatności aplikacji webowych, drugie na ochronę danych karty. Kiedy oba wskazują ten sam element architektury, planowanie testów bez inwentaryzacji skryptów w checkoucie jest trudne do obronienia.

Minimum dla sklepu to lista wszystkich skryptów ładowanych na stronie koszyka i płatności, z właścicielem biznesowym każdego z nich. Do tego decyzja, które są tam naprawdę potrzebne, i proces zatwierdzania nowych tagów. Po stronie technicznej służą do tego dwa mechanizmy. Polityka Content Security Policy ogranicza źródła wykonywanego kodu, a atrybut Subresource Integrity blokuje załadowanie skryptu o zmienionej treści. Oba działają tylko wtedy, gdy ktoś utrzymuje ich konfigurację po każdej zmianie w checkoucie. Pełne omówienie pozostałych kategorii znajdziesz w naszym wpisie o tym, co każda kategoria OWASP Top 10 oznacza w praktyce.

Co przetestować krok po kroku

Przetestuj w tej kolejności: skrypty w checkoucie, logikę ceny i rabatu, kontrolę dostępu do cudzych zamówień, uwierzytelnianie i sesję, API i integracje, wersje komponentów, konfigurację serwera, wydajność, a na końcu retest poprawek. Kolejność idzie od największego do mniejszego wpływu na transakcję, więc nawet skrócony zakres obejmie to, co najważniejsze. Metodyka aplikacji webowych opiera się na OWASP Web Security Testing Guide 4.2, warstwa API na OWASP API Security Top 10 z 2023 roku, a proces prowadzenia oceny na NIST SP 800-115.

1. Inwentaryzacja skryptów i integracji w checkoucie – spisz każdy skrypt, tag i widżet ładowany na stronie koszyka i płatności, ustal jego właściciela i uzasadnienie biznesowe, usuń wszystko, czego nie da się obronić.
2. Logika ceny, rabatu i kuponu – sprawdź, czy cena, wartość rabatu, koszt dostawy i podatek są wyliczane wyłącznie po stronie serwera. Zweryfikuj też, czy kupony da się łączyć, powielać albo stosować po terminie i czy zmiana koszyka po przejściu do płatności nie prowadzi do rozjazdu kwot.
3. Kontrola dostępu do cudzych zamówień i danych – przetestuj dostęp do zamówień, faktur, adresów i historii zakupów innego konta przez modyfikację identyfikatorów w adresie URL i w żądaniach API. To obszar A01:2025 Broken Access Control.
4. Uwierzytelnianie, sesja i panel administracyjny – zweryfikuj politykę haseł, odporność na przejmowanie kont i poprawność resetu hasła. Sprawdź unieważnianie sesji po wylogowaniu i zmianie hasła, drugi składnik uwierzytelniania dla administratorów oraz to, czy panel jest wystawiony publicznie bez potrzeby.
5. API sklepu i integracje z magazynem oraz kurierem – sprawdź autoryzację na poziomie obiektu i funkcji, limity zapytań, walidację danych wejściowych i to, czy endpointy integracyjne nie zwracają więcej danych, niż wymaga tego proces.
6. Wersje platformy, motywu i wtyczek – porównaj zainstalowane wersje z aktualnymi wydaniami i poprawkami bezpieczeństwa producenta, ze szczególną uwagą na komponenty modyfikujące checkout i płatności.
7. Konfiguracja serwera, nagłówki, kopie zapasowe i odtworzenie – zweryfikuj nagłówki bezpieczeństwa, konfigurację TLS, dostęp do plików konfiguracyjnych i repozytoriów oraz ekspozycję środowisk testowych. Sprawdź też faktyczne odtworzenie kopii zapasowej, a nie samo jej wykonanie, bo to krok pomijany najczęściej.
8. Wydajność i odporność na ruch szczytowy – sprawdź zachowanie sklepu przy zwielokrotnionym ruchu, w tym limity po stronie bramki płatniczej i integracji, oraz to, czy mechanizmy ograniczające ruch nie blokują prawdziwych klientów.
9. Retest poprawek – po wdrożeniu zmian powtórz testy dla wszystkich potwierdzonych podatności i sprawdź, czy poprawka nie wprowadziła nowego błędu w sąsiedniej funkcji.

W projektach, które prowadzimy, regularnie spotykamy w sklepach ten sam wzorzec. Nie jest to egzotyczna podatność techniczna, tylko błąd w logice ceny i rabatu. Aplikacja poprawnie liczy cenę przy dodaniu produktu do koszyka. Po zastosowaniu kuponu lub zmianie ilości przelicza jednak tylko część składników zamówienia i przyjmuje wartość przesłaną z przeglądarki. Efektem jest zamówienie opłacone kwotą niższą niż należna, bez żadnego alertu w systemie. Jak taki scenariusz wygląda w pełnym teście, opisaliśmy w case study wykrycia podatności price manipulation w checkoucie.

Krok szósty warto potraktować poważniej, niż sugeruje jego pozycja na liście. W bazie NVD prowadzonej przez NIST znajduje się CVE-2025-54236 dotyczące Adobe Commerce i Magento, z oceną CVSS 3.1 na poziomie 9.1 (CRITICAL). Błąd niepoprawnej walidacji danych wejściowych prowadzi do przejęcia sesji, a jego wykorzystanie nie wymaga interakcji użytkownika. Dotyczy wersji 2.4.9-alpha2, 2.4.8-p2, 2.4.7-p7, 2.4.6-p12, 2.4.5-p14, 2.4.4-p15 i wcześniejszych. Sprawdzenie wersji rdzenia platformy zajmuje kilka minut i lepiej zrobić to przed sezonem niż w jego trakcie.

Harmonogram testów: ile czasu potrzebujesz przed szczytem

Testy trzeba zakończyć na tyle wcześnie, by zmieścić poprawki i retest przed zamrożeniem zmian, czyli przed code freeze. To jedyne kryterium, które naprawdę decyduje o terminie. Raport z podatnościami dostarczony na tydzień przed Black Friday ma niewielką wartość, bo zespół i tak nie wdroży wtedy zmian w checkoucie.

Poniższy harmonogram pokazuje układ stosowany w projektach sezonowych. Terminy liczone są wstecz od dnia szczytu sprzedaży i wymagają dopasowania do wielkości sklepu oraz liczby integracji.

Harmonogram testów bezpieczeństwa sklepu liczony wstecz od dnia szczytu sprzedaży

Termin	Co robisz	Dlaczego wtedy
10–8 tygodni przed szczytem	Ustalenie zakresu, inwentaryzacja aplikacji, ról, integracji i skryptów w checkoucie	Zakres ustalony na podstawie faktycznej listy zasobów, a nie pamięci zespołu, decyduje o jakości całego testu
8–6 tygodni przed szczytem	Testy penetracyjne sklepu i panelu administracyjnego, w tym logika ceny i kontrola dostępu	Błędy w tych obszarach wymagają zmian w kodzie, a te potrzebują czasu na wdrożenie i regresję
6–5 tygodni przed szczytem	Testy API oraz integracji z magazynem, płatnościami i kurierem	Poprawki po stronie integracji zależą od dostawców zewnętrznych, którzy pracują we własnym rytmie
5–4 tygodnie przed szczytem	Wdrażanie poprawek przez zespół deweloperski i dostawców wtyczek	To ostatni moment, w którym zmiany w checkoucie można wdrożyć bez presji sprzedażowej
4–3 tygodnie przed szczytem	Retest poprawek i ponowna weryfikacja skryptów strony płatności	Poprawka bez potwierdzenia jest tylko deklaracją, a nowe tagi marketingowe pojawiają się właśnie przed sezonem
3–2 tygodnie przed szczytem	Testy wydajności i odporności na ruch szczytowy, próbne odtworzenie kopii zapasowej	Środowisko jest już stabilne po poprawkach, więc wyniki odpowiadają temu, co pojedzie na produkcję
2 tygodnie przed szczytem	Code freeze, wyłącznie poprawki krytyczne, monitorowanie integralności skryptów płatności	Każda niekonieczna zmiana w tym oknie zwiększa ryzyko awarii dokładnie wtedy, gdy sprzedaż jest największa
W trakcie szczytu	Brak testów inwazyjnych, monitorowanie, gotowa procedura reagowania i kontakty do dostawców	Nie da się wtedy bezpiecznie wdrożyć poprawki, więc jedyne, co realnie działa, to szybkie wykrycie i reakcja

Czego nie testować na produkcji w szczycie sprzedaży

W szczycie sprzedaży na produkcji nie prowadzimy testów, które mogą zmienić dane, obciążyć system albo zablokować proces zakupowy. Dotyczy to testów wydajnościowych, prób wstrzykiwania danych, masowego wyliczania identyfikatorów zamówień, testów mechanizmów blokowania kont oraz wszystkiego, co generuje zamówienia lub płatności testowe w systemie produkcyjnym.

Właściwym miejscem dla takich testów jest środowisko odpowiadające produkcji konfiguracją, wersjami komponentów i zestawem integracji, ale zasilone danymi syntetycznymi. Kopiowanie bazy produkcyjnej na środowisko testowe bez anonimizacji tworzy nowy zbiór danych osobowych o słabszych zabezpieczeniach, co trudno pogodzić z wymogiem doboru środków odpowiednich do ryzyka z art. 32 RODO.

Jeżeli część testów musi objąć produkcję, ustalamy wcześniej okno testowe poza godzinami największego ruchu, listę wykluczonych technik, oznaczenie ruchu testowego oraz osobę dyżurną po stronie sklepu. Uprzedź też dostawcę hostingu i operatora płatności, żeby aktywność testowa nie została uznana za incydent.

Osobna kwestia dotyczy tego, czego nie da się przetestować po swojej stronie. Podszywanie się pod sklep w kampaniach phishingowych i fałszywe witryny sprzedażowe działają poza infrastrukturą sprzedawcy. CERT Polska prowadzi konsumencki poradnik „Uważaj na fałszywe sklepy online!”, który warto znać, bo opisuje sygnały rozpoznawane przez klientów. Podszycie się pod markę sklepu zgłasza się natomiast jako incydent do CERT Polska.

Co wpływa na koszt testu bezpieczeństwa sklepu

Koszt testu zależy od pracochłonności, a ta wynika z zakresu, nie z typu firmy. Kwota podana bez zakresu wprowadza w błąd, bo ten sam „test sklepu” może oznaczać dwudniową weryfikację jednej ścieżki zakupowej albo kilkutygodniowy projekt obejmujący aplikację, panel, API i infrastrukturę. Dlatego zamiast liczby znajdziesz niżej czynniki, które realnie decydują o pracochłonności, a widełki przypisane do zdefiniowanych wariantów zakresu są w cenniku usługi.

Na pracochłonność wpływają przede wszystkim:

• Liczba i typ aplikacji – sam sklep, czy także panel partnera, aplikacja mobilna i strony wspierające sprzedaż.
• Liczba ról i ścieżek – gość, klient zalogowany, klient biznesowy, obsługa zamówień, administrator; każda kombinacja to osobne scenariusze kontroli dostępu.
• Obecność API – publiczne lub integracyjne interfejsy testuje się osobno, według OWASP API Security Top 10.
• Zakres retestu – czy po poprawkach potrzebne jest ponowne potwierdzenie i w jakiej formie.
• Wymóg potwierdzenia dla partnera – raport dla operatora płatności, klienta korporacyjnego lub audytora zwykle wymaga dodatkowego dokumentu i ustandaryzowanej formy wyników.
• Model dostępu – testy z dokumentacją i kontem testowym są szybsze niż podejście bez wiedzy o systemie.
• Termin – projekt realizowany w trybie pilnym tuż przed sezonem angażuje zespół kosztem innych prac.

Konkretny przedział cenowy podajemy w sekcji cennika przy opisie usługi testów penetracyjnych aplikacji i API, gdzie widełki są przypisane do zdefiniowanych wariantów zakresu. Jeżeli chcesz oszacować własny przypadek, najszybszą drogą jest konfigurator zakresu testów bezpieczeństwa, który przekłada odpowiedzi o aplikacji, rolach i integracjach na propozycję zakresu.

Najczęstsze pytania o bezpieczeństwo sklepu internetowego

Czy sklep na gotowej platformie w abonamencie też trzeba testować?

Tak. Dostawca gotowej platformy odpowiada za bezpieczeństwo swojego kodu, ale sklep odpowiada za konfigurację, motyw, wtyczki, integracje, uprawnienia użytkowników i skrypty firm trzecich w checkoucie. Błędy logiki ceny i kontroli dostępu powstają właśnie w tej warstwie. Test obejmuje wtedy wdrożoną instancję sklepu, a nie kod źródłowy dostawcy platformy.

Czy sklepowi wystarczy sam skan podatności przed sezonem?

Nie wystarczy, bo skan wykrywa znane błędy na podstawie wersji komponentów i typowych sygnatur, a w sklepie największe straty powodują błędy logiki zakupu. Skaner nie wie, ile powinien kosztować produkt po rabacie, czy dwa kupony wolno łączyć ani czyje zamówienie widzi zalogowany klient. Te scenariusze sprawdza człowiek w teście penetracyjnym, a skan jest przed nim etapem porządkującym wersje komponentów.

Kiedy najpóźniej zamówić test przed Black Friday?

Na tyle wcześnie, by zmieścić testy, poprawki i retest przed zamrożeniem zmian, czyli mniej więcej dziesięć tygodni przed szczytem sprzedaży. Poprawki w checkoucie wymagają czasu na wdrożenie i testy regresji, a część zmian zależy od dostawców wtyczek i integracji, którzy pracują we własnym rytmie. Test zakończony na tydzień przed szczytem daje raport, którego nie da się wdrożyć.

Dlaczego skrypty zewnętrzne w checkoucie są traktowane osobno?

Bo sklep nie kontroluje ich treści, a mimo to działają na stronie, na której klient wpisuje dane płatnicze. OWASP w edycji Top 10:2025 wyodrębnił kategorię A03:2025 Software Supply Chain Failures. PCI Security Standards Council w wytycznych do wymagań 6.4.3 i 11.6.1 oczekuje autoryzacji skryptów strony płatności, potwierdzania ich integralności i monitorowania prób manipulacji. Po stronie technicznej służą do tego Content Security Policy i Subresource Integrity.

Czy test bezpieczeństwa można przeprowadzić na środowisku produkcyjnym?

Można, ale poza szczytem sprzedaży i przy ustalonych ograniczeniach. Na produkcji odpada część technik, w tym testy wydajnościowe, masowe wyliczanie identyfikatorów i próby blokowania kont. Bezpieczniejsze jest środowisko odpowiadające produkcji konfiguracją i wersjami komponentów, zasilone danymi syntetycznymi zamiast kopią bazy klientów. Jeśli testy muszą objąć produkcję, ustalamy okno testowe, listę wykluczonych technik i kontakt dyżurny.

Jak Pentestica może pomóc

Prowadzimy testy penetracyjne aplikacji sklepowych, paneli administracyjnych, API i infrastruktury, pracując według OWASP Web Security Testing Guide, OWASP API Security Top 10, PTES i NIST SP 800-115. Wyniki mapujemy na zabezpieczenia z Załącznika A normy ISO/IEC 27001:2022 wtedy, gdy klient potrzebuje ich w tej formie. Mamy ponad 10 lat doświadczenia i setki zrealizowanych projektów. W obszarze e-commerce szczególną uwagę poświęcamy logice ceny i rabatu, kontroli dostępu do zamówień oraz skryptom firm trzecich na stronie płatności.

Zakres ustalamy przed startem, a po wdrożeniu poprawek wykonujemy retest, żeby potwierdzić skuteczność zmian. Poza testami wspieramy sklepy w audycie bezpieczeństwa IT oraz w roli vCISO, gdy potrzebny jest stały nadzór nad procesem, a nie jednorazowe badanie. Zakres i termin najłatwiej wstępnie określić, wypełniając formularz doboru zakresu testów.

Źródła

• OWASP Top 10:2025 – aktualna lista kategorii ryzyka aplikacji webowych, w tym nowa kategoria A03:2025 Software Supply Chain Failures.
• OWASP API Security Top 10 – 2023 – najnowsza edycja listy ryzyk dla interfejsów API.
• OWASP Web Security Testing Guide 4.2 – metodyka testowania bezpieczeństwa aplikacji webowych, wersja stabilna.
• PCI SSC, „Payment Page Security and Preventing E-Skimming – Guidance for PCI DSS Requirements 6.4.3 and 11.6.1” (10 marca 2025) – wytyczne dotyczące autoryzacji, integralności i monitorowania skryptów strony płatności.
• Biblioteka dokumentów PCI DSS – aktualna wersja standardu PCI DSS v4.0.1, opublikowana 11 czerwca 2024.
• NIST SP 800-115 „Technical Guide to Information Security Testing and Assessment” (2008) – metodyka planowania i prowadzenia testów bezpieczeństwa.
• NVD, wpis CVE-2025-54236 – podatność w Adobe Commerce/Magento, CVSS 3.1 równe 9.1 (CRITICAL), lista wersji podatnych.
• CERT Polska, „Uważaj na fałszywe sklepy online!” – poradnik o fałszywych sklepach internetowych i ścieżka zgłaszania incydentów.
• RODO, rozporządzenie 2016/679, art. 32 – wymóg bezpieczeństwa przetwarzania danych osobowych.