Audyt bezpieczeństwa sprzedaży internetowej przed Black Friday. Co sprawdzić, zanim ruch, boty i ścieżka zakupu obciążą sklep?

Audyt bezpieczeństwa sprzedaży internetowej to uporządkowany przegląd ryzyk, które mogą zatrzymać sprzedaż, ujawnić dane klientów albo zwiększyć koszt obsługi awarii. W praktyce powinien łączyć przegląd architektury, testy aplikacji, testy połączeń między systemami, przegląd konfiguracji infrastruktury, analizę dzienników działania, testy obciążeniowe wybranych ścieżek i warsztat decyzyjny z biznesem.

Dla sklepu z oddzieloną warstwą klienta lub sprzedaży firmowej szczególnie ważne są granice między sklepem Next.js, zapleczem NestJS, rdzeniem sprzedażowym MedusaJS, PostgreSQL, płatnościami, systemem finansowo-magazynowym, bazą produktów, magazynem i narzędziami automatyzacji marketingu. Awaria rzadko zatrzymuje się w jednej warstwie. Brak limitu zapytań w połączeniu między systemami może skończyć się kolejką maili, rachunkiem za SMS-y, opóźnioną synchronizacją stanów i nieprawidłową obietnicą dostawy w koszyku.

Lista OWASP dla bezpieczeństwa połączeń między systemami z 2023 roku wskazuje brak kontroli dostępu do konkretnego obiektu jako pierwsze ryzyko takich połączeń. W praktyce każdy punkt dostępu, który przyjmuje identyfikator koszyka, zamówienia, faktury albo klienta, musi sprawdzić, czy zalogowany użytkownik naprawdę może wykonać akcję na tym rekordzie. W sprzedaży internetowej to nie jest abstrakcja. Dotyczy koszyka, zamówienia, faktury, adresu dostawy, listy życzeń, konta firmowego, limitu kredytowego i panelu administracyjnego.

Drugim obszarem jest niekontrolowane zużywanie zasobów. Połączenia między systemami zużywają procesor, pamięć, przepustowość, e-mail, SMS, płatne walidacje, zdarzenia zewnętrzne i limity dostawców. W szczycie sprzedaży atak nie musi wykraść danych, żeby zaszkodzić biznesowi. Wystarczy, że przepali kolejkę, budżet SMS albo limit operatora płatności.

Trzecim obszarem jest niekontrolowany dostęp do wrażliwych procesów biznesowych. Bot nie musi łamać hasła, żeby robić szkody: może masowo rezerwować stan magazynowy, generować koszyki, testować kupony, zakładać konta, pobierać ceny albo przeciążać wyszukiwarkę. Audyt powinien sprawdzić nie tylko podatności techniczne, ale też automatyzację ścieżek, które mają sens biznesowy tylko w normalnym tempie.

Raporty Akamai State of the Internet 2025 wskazują wzrost globalnych ataków na aplikacje internetowe o 33% rok do roku oraz rosnące ryzyko związane z połączeniami systemowymi, botami i automatyzacją wspieraną przez sztuczną inteligencję. To ważne dla sprzedaży internetowej, bo ruch w szczycie sam w sobie wygląda nietypowo. Źle ustawiona obrona może przepuścić zły ruch albo zablokować realnych klientów.

Przegląd przed szczytem sprzedaży powinien więc obejmować nie tylko pytanie "czy mamy zaporę aplikacyjną?". Trzeba sprawdzić reguły dla poszczególnych punktów dostępu, limity dla klienta, konta, adresu IP i urządzenia, wyjątki dla połączeń z innymi systemami, mechanizmy wyzwań dla botów, pamięć podręczną, osłonę serwera źródłowego, kolejki, ograniczanie funkcji przy awarii i plan ręcznego zaostrzenia polityk, gdy kampania już trwa.

Najbardziej praktyczne testy nie symulują całego internetu. Symulują konkretne scenariusze: pobieranie listy produktów przez automaty, testowanie skradzionych loginów i haseł, masowe koszyki, spam rejestracji, siłowe sprawdzanie kuponów, nagły wzrost zapytań do wyszukiwarki, wiele równoległych powiadomień z bramki płatniczej i nagły wzrost żądań z jednego kraju albo sieci dostawcy. Każdy scenariusz powinien mieć oczekiwany sygnał w dziennikach działania i przypisaną decyzję operacyjną.

PCI Security Standards Council utrzymuje PCI DSS jako standard ochrony danych kart płatniczych; w praktyce zespół sprzedaży internetowej musi rozumieć, gdzie kończy się zakres odpowiedzialności operatora płatności, a gdzie zaczyna odpowiedzialność sklepu. Przekierowanie płatności do zewnętrznego operatora nie zwalnia z obowiązku bezpiecznej konfiguracji ścieżki zakupu, zdarzeń zewnętrznych, skryptów, logów i dostępu administracyjnego.

Przed szczytem trzeba sprawdzić, czy ponowione żądanie nie tworzy podwójnego zamówienia, czy status płatności jest walidowany, czy powiadomienia z bramki płatniczej mogą bezpiecznie przyjść kilka razy, czy dane nie ścigają się przy złożeniu zamówienia, jak działa częściowa awaria, czy dzienniki działania maskują dane, czy powiadomienia alarmowe pokazują wzrost odrzuconych płatności i czy istnieje instrukcja ręcznego uzgadniania transakcji. W sprzedaży firmowej dochodzą limity kredytowe, płatność fakturą, ścieżka akceptacji i reguły blokowania zamówień przeterminowanych klientów.

To jest moment, w którym bezpieczeństwo łączy się z architekturą produktu. Jeśli zamówienie może powstać bez potwierdzonej płatności, płatność może zostać zaksięgowana bez zamówienia albo stan magazynowy może zostać zarezerwowany bez czasu wygaśnięcia, ryzyko dotyczy finansów i operacji, nie tylko bezpieczeństwa.

W sprzedaży internetowej największe wycieki często nie zaczynają się od spektakularnego włamania. Zaczynają się od za szerokich uprawnień, błędnego filtra właściciela danych, logowania pełnej treści żądania, punktu diagnostycznego, niezabezpieczonej kopii zapasowej albo panelu administratora, który pozwala zobaczyć za dużo.

Jeśli system obsługuje platformę handlową, kupujących firmowych, wiele marek, hurtownie albo role organizacyjne, przegląd powinien sprawdzić izolację danych w PostgreSQL, na przykład kontrolę dostępu do pojedynczych wierszy, albo równoważny mechanizm. Taka izolacja nie zastępuje kontroli w aplikacji, ale daje dodatkową barierę, gdy kod punktu dostępu popełni błąd. Warto testować ją negatywnie: użytkownik z firmy A nie może zobaczyć koszyka, faktury, limitu kredytowego ani historii firmy B.

Dane to również czas przechowywania i dzienniki działania. Przed kampanią trzeba ustalić, które dane są potrzebne do diagnozy awarii, a których nie wolno zapisywać w dziennikach. Zespół powinien mieć gotowe zapytania do śledzenia anomalii, ale nie kosztem wyciągania wrażliwych danych do narzędzi, które nie powinny ich przechowywać.

Bez wglądu w działanie sklepu przegląd bezpieczeństwa kończy się prezentacją, a nie gotowością operacyjną. Zespół musi widzieć cztery grupy sygnałów: dostępność, konwersję, nadużycia i dostęp do danych. W praktyce oznacza to widoki nadzoru dla opóźnień w ścieżce zakupu, współczynnika błędów, nieudanych płatności, długości kolejek, wyzwań dla botów, zablokowanych żądań, nieudanych logowań, działań administratorów, ponowień zdarzeń zewnętrznych i nietypowych zapytań do danych.

Reakcja na awarie powinna być krótka i konkretna. Kto ma prawo zaostrzyć reguły zapory aplikacyjnej? Kto akceptuje wyłączenie kodu rabatowego? Kto informuje obsługę klienta, gdy rośnie liczba błędnych płatności? Kto decyduje o powrocie do poprzedniej wersji? Kto ma dostęp do operatora płatności, konfiguracji domen, sieci dostarczania treści i repozytorium? Jeśli odpowiedzi powstają dopiero w trakcie Black Friday, jest za późno.

Najprostszy test gotowości to ćwiczenie scenariuszowe. Przez 60-90 minut zespół przechodzi scenariusz: boty generują koszyki, opóźnienia w ścieżce zakupu rosną, operator płatności zwraca błędy, a marketing pyta, czy wyłączyć kampanię. Po takim ćwiczeniu widać więcej prawdy niż po dziesięciu spotkaniach statusowych.

W GMI patrzymy na bezpieczeństwo przez produkt i operacje, nie tylko przez listę podatności. Dla sklepów z oddzieloną warstwą klienta, sprzedaży firmowej i aplikacji mobilnych łączymy przegląd architektury, zaplecza oraz połączeń między systemami: Next.js, MedusaJS, NestJS, PostgreSQL, kolejek, płatności, systemów finansowych, produktowych i magazynowych, wydania mobilnego i nadzoru działania.

Najpierw w ramach rozpoznania biznesu, projektu i technologii ustalamy zakres bezpieczeństwa: mapujemy ścieżkę przychodu, dane wrażliwe, połączenia z innymi systemami, role, uprawnienia, punkty awarii i zależności od dostawców. Potem przygotowujemy priorytetyzowaną listę zadań: do naprawy przed szczytem, warto naprawić, obserwować, zaakceptować. Dla ustalonego zakresu możemy zaproponować naprawy po stałej cenie, a kod i dokumentacja zostają po stronie klienta.

To podejście jest szczególnie użyteczne, gdy sklep ma niestandardową ścieżkę zakupu, MedusaJS lub inny oddzielony rdzeń sprzedażowy, zaplecze NestJS, PostgreSQL, połączenia z systemem finansowo-magazynowym, bazą produktów i systemem magazynowym albo aplikację React Native/Expo. W takich systemach bezpieczeństwo jest częścią architektury sprzedaży, a nie dodatkiem instalowanym na końcu.