Audyt bezpieczeństwa aplikacji webowej — co wchodzi w zakres i jak przygotować aplikację

Audyt bezpieczeństwa aplikacji webowej obejmuje warstwę aplikacji, API, uwierzytelnianie, autoryzację, logikę biznesową i konfigurację środowiska, a przygotowanie sprowadza się do wydania kont testowych, danych i zgód. Punktem odniesienia dla zakresu jest OWASP Web Security Testing Guide (WSTG). Poniżej znajdziesz podział zakresu na elementy i listę rzeczy do przygotowania przed startem.

Co wchodzi w zakres audytu bezpieczeństwa aplikacji webowej

W zakres audytu bezpieczeństwa aplikacji webowej wchodzi dwanaście kategorii testów wymienionych w sekcji czwartej OWASP Web Security Testing Guide (WSTG). Sam audyt prowadzi się jako test penetracyjny aplikacji według tej metodyki; strona projektu podaje jako wydanie stabilne wersję 4.2 z 3 grudnia 2020 roku.

Te kategorie to: zbieranie informacji, testowanie konfiguracji i wdrożenia, zarządzanie tożsamością, uwierzytelnianie, autoryzacja, zarządzanie sesją, walidacja danych wejściowych, obsługa błędów, słaba kryptografia, logika biznesowa, warstwa kliencka oraz API. Można je wskazać wprost w zakresie zlecenia.

Głębokość badania wyznacza poziom weryfikacji. Definicje poziomów cytujemy za OWASP Application Security Verification Standard (ASVS) 4.0.3. Level 1 to niski poziom zaufania, w całości weryfikowalny testem penetracyjnym. Level 2 dotyczy aplikacji z danymi wrażliwymi i jest poziomem rekomendowanym dla większości aplikacji, a Level 3 obejmuje aplikacje najbardziej krytyczne. Sam katalog ryzyk opisuje wpis o kategoriach ryzyka OWASP Top 10.

Element zakresu	Co trzeba dostarczyć przed startem	Czego nie da się sprawdzić bez tego
Aplikacja webowa i jej domeny	Lista domen, subdomen i adresów IP	Zapomnianych subdomen i starych wersji
Warstwa API	Specyfikacja OpenAPI, kolekcja Postman, lista endpointów	Autoryzacji na poziomie obiektu i funkcji
Konta i role	Konto dla każdej roli, dwa w rolach z własnymi danymi	Eskalacji uprawnień poziomej i pionowej
Integracje i systemy trzecie	Wykaz integracji, właścicieli i zgód	Przepływów danych na zewnątrz
Dane testowe	Rekordy, pliki i płatności w trybie sandbox	Logiki biznesowej: rabatów i limitów
Środowisko	Adres środowiska, dostęp VPN, kontakt techniczny	Błędów konfiguracji i wdrożenia
Ograniczenia techniczne	Reguły WAF, limity zapytań, lista dozwolonych adresów	Podatności ukrytych za blokadą ruchu

Jak opisać zakres, żeby nic nie wypadło poza test

Zakres opisuje się przez wyliczenie konkretnych zasobów, nie przez nazwę produktu. Penetration Testing Execution Standard (PTES) w rozdziale Pre-engagement Interactions wymaga jawnego wskazania adresów IP i domen oraz dat startu i zakończenia; osobno omawia ryzyko rozrostu zakresu (scope creep).

• Domeny i subdomeny — wypisz każdą nazwę hosta osobno, razem ze środowiskami staging i adresami IP. Subdomena pominięta w dokumencie zostaje poza testem.
• Warstwa API — OWASP WSTG w wersji stabilnej dokumentuje w kategorii API Testing wyłącznie testowanie GraphQL, więc REST opisz samodzielnie: specyfikacja OpenAPI, kolekcja Postman, lista endpointów i wersji. Nieopisane wersje endpointów to przypadek API9:2023 Improper Inventory Management.
• Integracje i systemy trzecie — bramki płatnicze, dostawcy tożsamości i systemy partnerów wymagają zgody właściciela; wpisz je razem z zakresem dozwolonych działań.
• Panele administracyjne — zaplecze ma inne role i funkcje niż część publiczna, więc traktuj je jako odrębny zasób z własnym adresem i sposobem dostępu.
• Aplikacja mobilna — klient mobilny to osobna pozycja, nawet przy wspólnym API: wymaga innych narzędzi i testowej wersji aplikacji.

Strukturę takiego dokumentu porządkuje wzór zakresu testu penetracyjnego.

Jakie konta i role testowe przygotować

Podstawa to jedno działające konto dla każdej roli w aplikacji, łącznie z administratorem. W rolach, w których użytkownik ma własne dane — klient, pacjent, kontrahent — potrzebne są dwa konta w tej samej roli: bez drugiego nie sprawdzisz, czy jeden użytkownik widzi dane drugiego. To przypadek A01:2025 Broken Access Control oraz API1:2023 Broken Object Level Authorization.

Konta muszą działać w dniu startu. W projektach, które prowadzimy, pierwszy dzień najczęściej opóźniają konta wygasłe, zablokowane po kilku nieudanych logowaniach albo powiązane z drugim składnikiem uwierzytelniania na prywatnym telefonie osoby z zespołu klienta. Ustal, kto odblokuje konto w trakcie testu.

Kwestionariusz PTES pyta między innymi o pięć rzeczy: liczbę systemów logowania, dostęp do kodu źródłowego, istnienie dokumentacji, testy oparte na rolach i skanowanie z uwierzytelnieniem. Odpowiedzi przesądzają o pracochłonności i o tym, czy test obejmie kontrolę dostępu między rolami.

Testować na produkcji czy na kopii środowiska

Na produkcji testuj wtedy, gdy nie istnieje wierna kopia środowiska, a badanie ma objąć rzeczywistą konfigurację WAF-a, CDN-u i integracji. Na kopii testuj wtedy, gdy aplikacja obsługuje płatności, dane medyczne albo procesy nieodwracalne. Kopia jest też właściwym wyborem, gdy testy z uwierzytelnieniem zmieniają stan danych produkcyjnych.

Kopia ma sens tylko wtedy, gdy odpowiada produkcji: ta sama wersja aplikacji, ta sama konfiguracja serwera, te same reguły WAF-a i ten sam zestaw integracji, choćby w trybie sandbox. Kopia z wyłączonym WAF-em daje wyniki, których nie da się przenieść.

Wariant mieszany też jest dopuszczalny: rozpoznanie na produkcji, a działania zmieniające dane — rejestracja, zamówienia, operacje masowe — na kopii. Podział zapisz w regułach zaangażowania; szablon Rules of Engagement zawiera załącznik B publikacji NIST SP 800-115.

Co uzgodnić z dostawcą hostingu, chmurą i zespołem od WAF-a

Uzgodnij cztery rzeczy: pisemną zgodę właściciela infrastruktury, okno testowe, limity zapytań i wyłączenie testów odmowy usługi. PTES wymienia tu usługi chmurowe, operatora łącza, hosting, MSSP oraz kraje, w których stoją serwery.

Chmura ma własne reguły. Polityka Amazon Web Services „Penetration Testing” pozwala testować wskazane usługi bez uprzedniej zgody, ale testy obejmujące Command and Control (C2) wymagają akceptacji. Zabronione są między innymi Denial of Service, Distributed Denial of Service i ich symulacje, port flooding, protocol flooding oraz request flooding.

Microsoft w dokumencie „Security Testing Rules of Engagement” dopuszcza testy wyłącznie we własnym tenancie lub na zasobach z wyraźnym upoważnieniem. Testów odmowy usługi zabrania, a ataki DDoS wyklucza bezwarunkowo.

Po stronie WAF-a ustal dwie rzeczy: czy adresy zespołu trafią na listę dozwolonych i jakie limity zapytań obowiązują. Bez tego test odporności na nadmierne zużycie zasobów (API4:2023 Unrestricted Resource Consumption) trzeba pominąć. Z naszej praktyki wynika, że automatyczna blokada potrafi odciąć zespół po pierwszej godzinie i reszta okna przepada; dlatego z góry ustalamy, kto po stronie klienta może ją zdjąć.

Przygotowanie aplikacji w siedmiu krokach

Przygotowanie zamyka się w siedmiu krokach, które warto wykonać na tydzień przed startem. Gdy badanie ma objąć także infrastrukturę i procesy, punktem wyjścia jest audyt bezpieczeństwa IT.

1. Spisz zakres: domeny, subdomeny, adresy IP, endpointy API, panele administracyjne i aplikację mobilną.
2. Załóż konta testowe według reguły z sekcji o rolach i sprawdź logowanie dzień przed startem.
3. Przekaż dokumentację: specyfikację OpenAPI, kolekcję Postman, schemat GraphQL i opis nietypowych procesów.
4. Przygotuj dane testowe oraz tryb sandbox dla płatności i wysyłki wiadomości, żeby testy nie dotknęły klientów.
5. Wykonaj kopię zapasową i sprawdź jej odtworzenie, zwłaszcza przy badaniu na produkcji.
6. Zbierz zgody hostingu, chmury i zespołu od WAF-a; zapisz okno testowe oraz limity zapytań.
7. Wyznacz kontakt awaryjny po obu stronach i ustal ścieżkę zgłaszania podatności krytycznych.

Najczęstsze pytania o zakres audytu aplikacji webowej

Czy audyt bezpieczeństwa aplikacji webowej wymaga dostępu do kodu źródłowego?

Nie wymaga, ale dostęp do kodu zmienia głębokość badania. Test bez kodu pokazuje aplikację z perspektywy atakującego, a test z kodem pozwala potwierdzić przyczynę podatności i sprawdzić fragmenty trudne do osiągnięcia z zewnątrz. Kwestionariusz PTES pyta wprost, czy kod źródłowy zostanie udostępniony, więc decyzję podejmij przed zamknięciem zakresu.

Ile kont testowych trzeba przygotować?

Co najmniej jedno konto na każdą rolę, a w rolach z własnymi danymi użytkownika — dwa. Konta w różnych rolach służą do sprawdzenia eskalacji uprawnień, a dwa konta w tej samej roli — dostępu do cudzych danych. Jeśli aplikacja dzieli dane między organizacje, przygotuj komplet kont także w drugiej organizacji testowej.

Czy trzeba wyłączyć WAF na czas testu?

Nie trzeba, ale wariant wybierz świadomie. Test przez włączony WAF mierzy skuteczność blokad w rzeczywistych warunkach, a test z adresami zespołu na liście dozwolonych pokazuje podatności samej aplikacji, które blokada tylko zasłania. Praktyczne rozwiązanie to dwa przebiegi w jednym oknie testowym i opis obu wyników w raporcie.

Czy test penetracyjny w chmurze wymaga zgody dostawcy?

Zależy od dostawcy i od rodzaju testu, więc regulamin sprawdź przed podpisaniem zakresu. U głównych dostawców chmury część usług można testować bez odrębnej zgody, ale symulacje odmowy usługi są zabronione, a testy z użyciem infrastruktury sterującej wymagają wcześniejszej akceptacji. Osobno potrzebna jest zgoda właściciela każdego zasobu, którego nie kontrolujesz, w tym systemów partnerów i dostawców SaaS.

Od czego zależy koszt audytu bezpieczeństwa aplikacji webowej?

Koszt składa się z pracochłonności testu, przygotowania raportu i retestu. Przesuwają go: liczba ról i systemów logowania, liczba endpointów API, tryb dostępu do kodu oraz wybór środowiska. Każda z tych zmiennych zmienia wycenę, dlatego widełki orientacyjne znajdziesz w sekcji cennika na stronie usługi testów penetracyjnych.

Jak Pentestica może pomóc

Prowadzimy testy penetracyjne aplikacji webowych i API według OWASP WSTG i PTES, z ponad 10-letnim doświadczeniem i setkami zrealizowanych projektów. Zakres ustalamy przed startem: role, endpointy, środowisko, ograniczenia po stronie WAF-a i zasady zgłaszania podatności krytycznych. Raport zawiera potwierdzone podatności, dowód ich wykorzystania i rekomendacje uszeregowane według priorytetu, a po wdrożeniu poprawek wykonujemy retest. Wstępny zakres złożysz w konfiguratorze zakresu.

Źródła

Wydania i wersje dokumentów wymienionych niżej sprawdzono na stronach OWASP, NIST, PTES, AWS i Microsoft 8 września 2026 roku.

• OWASP Web Security Testing Guide (WSTG), wersja stabilna 4.2 — metodyka testowania aplikacji webowych i podział sekcji czwartej na dwanaście kategorii.
• OWASP Application Security Verification Standard (ASVS) — strona projektu — informacje o standardzie, jego wydaniach i zakresie zastosowania.
• OWASP ASVS 4.0.3, rozdział „Using the ASVS” — definicje poziomów weryfikacji Level 1, Level 2 i Level 3.
• OWASP API Security Top 10, edycja 2023 — lista ryzyk specyficznych dla API, w tym API1:2023, API4:2023 i API9:2023.
• OWASP Top 10, wydanie 2025 — ranking kategorii ryzyka w aplikacjach webowych, z A01:2025 Broken Access Control na pierwszym miejscu.
• NIST SP 800-115, Technical Guide to Information Security Testing and Assessment — metodyka testu penetracyjnego oraz szablon Rules of Engagement w załączniku B.
• Penetration Testing Execution Standard (PTES), Pre-engagement Interactions — kwestionariusz dla aplikacji webowych, zasady ustalania zakresu i współpraca ze stronami trzecimi.
• Amazon Web Services, Penetration Testing (Customer Support Policy) — zakres testów dozwolonych bez zgody oraz lista działań zabronionych.
• Microsoft, Security Testing Rules of Engagement — warunki testowania własnych zasobów i zakaz testów odmowy usługi.