OWASP WSTG v4.2
Aplikacje webowe
Portale klientów, systemy transakcyjne, panele administracyjne, sklepy i strony firmowe.
- Uwierzytelnianie, sesja i uprawnienia
- Logika biznesowa
- OWASP Top 10:2025
Cyberbezpieczeństwo · Testy penetracyjne
Testy penetracyjne aplikacji, API i infrastruktury
Testy penetracyjne to kontrolowany atak na Twój system, prowadzony za pisemną zgodą, który pokazuje, co naprawdę może zrobić atakujący - i jak temu zapobiec. Testujemy aplikacje webowe i mobilne, API, infrastrukturę, chmurę oraz kod źródłowy dla firm z sektorów regulowanych i każdej organizacji, która woli wiedzieć niż zgadywać.
innovix-audit --target api.firma.example --wstg v4.2[*] OWASP WSTG v4.2 scan initiatedOKTLS: A+ hardened (TLS 1.3, HSTS preload)OKSecurity headers: compliant!!/api/users/:id - IDOR (CVSS 7.5)!!/api/upload - missing rate limitOKCSRF tokens: HMAC-SHA256OKSession: HttpOnly + Secure + SameSite=Strict14 findings · CVSS median 4.7 · raport w 5 dni01Definicja
Czym jest test penetracyjny
Test penetracyjny (pentest) to autoryzowana symulacja ataku na system informatyczny: tester szuka podatności i bezpiecznie je wykorzystuje tak, jak zrobiłby to prawdziwy atakujący, ale w uzgodnionym zakresie i bez szkody dla systemu. Wynikiem jest raport z potwierdzonymi podatnościami, dowodami technicznymi i rekomendacjami naprawy.
Pentest odpowiada na pytanie, które interesuje zarząd i zespół techniczny jednocześnie: co konkretnie może zrobić osoba, która chce zaszkodzić firmie - odczytać dane klientów, przejąć konto administratora, zmienić kwotę przelewu? Automatyczny skan podatności i audyt zgodności odpowiadają na inne pytania. Wszystkie trzy narzędzia się uzupełniają, ale nie zastępują.
| Kryterium | Skan podatności | Test penetracyjny | Audyt zgodności |
|---|---|---|---|
| Pytanie | Jakie znane błędy mogą występować? | Co atakujący naprawdę może zrobić w tym systemie? | Czy organizacja spełnia wymagania normy lub przepisu? |
| Sposób | Narzędzie automatyczne, sygnatury znanych podatności | Ręczne testy eksperta wspierane narzędziami, łączenie podatności w łańcuchy | Przegląd dokumentów i procesów, wywiady, próbki dowodów |
| Błędy logiki i uprawnień | Wykrywa rzadko | Główny obszar testów ręcznych | Nie bada działania systemu |
| Fałszywe alarmy | Częste, wymagają weryfikacji | Każde ustalenie potwierdzone dowodem | Nie dotyczy |
| Wynik | Lista potencjalnych problemów | Raport z dowodami, oceną CVSS i rekomendacjami | Lista wymagań spełnionych i niespełnionych |
| Kiedy | Stale, np. w potoku CI/CD | Przed wdrożeniem, po dużych zmianach, cyklicznie | Przed certyfikacją, na żądanie regulatora lub klienta |
02Kiedy
Kiedy potrzebujesz testu penetracyjnego
Najczęstsze powody, dla których firmy zlecają pentest - od zmian w systemie po wymagania regulatorów i klientów.
- Przed wdrożeniem lub po dużej zmianie - nowa aplikacja, nowy moduł, integracja z partnerem, migracja do chmury. Podatność usunięta przed startem kosztuje mniej niż ta znaleziona po incydencie.
- NIS2 i ustawa o KSC - podmioty kluczowe i ważne muszą zapewnić bezpieczeństwo systemu informacyjnego, w tym jego testowanie, oraz stosować procedury oceny skuteczności środków bezpieczeństwa (art. 8 ust. 1 pkt 2 lit. b i h ustawy o KSC). Pentest jest najbardziej bezpośrednim sprawdzianem zabezpieczeń technicznych. Zobacz też audyt NIS2/KSC.
- DORA - podmioty finansowe prowadzą program testowania operacyjnej odporności cyfrowej, który obejmuje m.in. testy penetracyjne i przeglądy kodu źródłowego (art. 24-25), a wybrane z nich - zaawansowane testy TLPT co najmniej raz na 3 lata (art. 26). Więcej o testach TLPT.
- RODO - art. 32 ust. 1 lit. d wymaga regularnego testowania, mierzenia i oceniania skuteczności środków chroniących dane osobowe.
- Wymagania klientów i działów zakupów - korporacje i instytucje coraz częściej proszą dostawców o aktualny raport z testu penetracyjnego przed podpisaniem umowy.
- Ubezpieczenie cyber - ubezpieczyciele pytają o testy bezpieczeństwa przy ocenie ryzyka.
- Due diligence - przed przejęciem firmy lub zakupem oprogramowania warto wiedzieć, ile kosztuje ukryty dług bezpieczeństwa.
03Zakres
Testy penetracyjne: co testujemy
Każdy typ systemu wymaga innej metodyki i innych narzędzi. Wybierz obszar, żeby zobaczyć szczegółowy zakres testów.
OWASP API Top 10 2023
API
REST, GraphQL, gRPC i webhooki - interfejsy aplikacji mobilnych, SPA i integracji B2B.
- Autoryzacja obiektów (BOLA)
- OAuth 2.0, OIDC i JWT
- Nadużycia przepływów biznesowych
OWASP MASVS 2.1
Aplikacje mobilne
Aplikacje iOS i Android razem z backendem, z którym się komunikują.
- Przechowywanie danych na urządzeniu
- Komunikacja i certificate pinning
- Analiza statyczna i dynamiczna
NIST SP 800-115
Infrastruktura i sieci
Perymetr widoczny z internetu oraz sieć wewnętrzna z Active Directory.
- Usługi wystawione do internetu i VPN
- Segmentacja i ruch boczny
- Eskalacja uprawnień w AD
CIS Benchmarks
Chmura
Konfiguracja i uprawnienia w AWS, Microsoft Azure i Google Cloud.
- IAM i role
- Magazyny danych i szyfrowanie
- Kontenery i Kubernetes
White box
Audyt kodu (white box)
Przegląd kodu źródłowego pod kątem podatności niewidocznych z zewnątrz.
- Logika autoryzacji i sekrety
- Zależności ze znanymi CVE
- Gotowe poprawki w raporcie
04Podejścia
Black box, grey box czy white box
Podejście określa, ile wiemy o systemie na starcie. Od niego zależy perspektywa ataku, głębokość testu i koszt.
| Podejście | Perspektywa | Co dostajemy od Ciebie | Co wykrywa najlepiej | Kiedy wybrać |
|---|---|---|---|---|
| Black box | Anonimowy atakujący z internetu | Tylko adresy lub zakres celów | Błędy konfiguracji, ujawnione dane, podatności dostępne bez logowania | Pierwsze badanie, szybka ocena ryzyka zewnętrznego |
| Grey box | Zalogowany użytkownik, klient lub partner | Konta testowe dla każdej roli, podstawowa dokumentacja | Eskalacja uprawnień, IDOR, błędy logiki biznesowej | Systemy z kontami użytkowników - najlepszy stosunek wyniku do kosztu |
| White box | Osoba z pełną wiedzą o systemie | Kod źródłowy, architektura, konfiguracja | Podatności w ścieżkach wewnętrznych, sekrety w kodzie, zależności z CVE | Systemy krytyczne, producenci oprogramowania, due diligence |
W praktyce najczęściej łączymy podejścia: Audyt Kompleksowy to black box z zewnątrz i grey box z kontami testowymi, a audyt kodu źródłowego (white box) dokładamy tam, gdzie liczy się każda ścieżka w kodzie.
05Pakiety
Pakiety testów bezpieczeństwa
Cztery warianty z naszej oferty - od szybkiego testu z zewnątrz po pełną ocenę z retestem i weryfikację zgodności.
-
Audyt Zewnętrzny
Black box z perspektywy zewnętrznego, anonimowego atakującego z internetu.
Indywidualnie wycena po krótkiej rozmowie zakresowej
- Rekonesans i rozpoznanie stosu technologicznego
- Nagłówki HTTP i konfiguracja TLS
- Reflected XSS, enumeracja endpointów, fuzzing katalogów
- Analiza generowania tokenów sesji po stronie klienta
- Publiczne błędy konfiguracji, kopie zapasowe plików, ujawnione ścieżki
- Wynik
- Zwykle 6-12 ustaleń z oceną CVSS
- Dla kogo
- Pierwsze badanie systemu, weryfikacja po wdrożeniu, szybka ocena ryzyka zewnętrznego
-
Audyt Kompleksowy
Black box z zewnątrz, grey box z uwierzytelnieniem i retest po naprawach w jednej umowie.
Indywidualnie wycena po krótkiej rozmowie zakresowej
- Poziom 1: rekonesans, TLS, nagłówki HTTP, reflected XSS, enumeracja, błędy konfiguracji
- Poziom 2: IDOR, eskalacja uprawnień, SQLi, XXE, CSRF, kryptografia, logika biznesowa
- Minimum 67 testów w 12 kategoriach OWASP WSTG v4.2
- Retest każdej podatności z nowym dowodem technicznym
- Executive Summary dla zarządu i opis łańcucha ataku
- Wynik
- Raport końcowy (część black box i grey box) i certyfikat po naprawach
- Dla kogo
- Finanse, ubezpieczenia, ochrona zdrowia i duże organizacje objęte DORA lub NIS2/KSC
-
Rewizja kodu źródłowego
White box - rozszerzenie Audytu Kompleksowego o analizę kodu backendu.
Indywidualnie wycena zależy od wielkości i technologii kodu
- Logika autoryzacji, sekrety zapisane w kodzie, błędne warunki dostępu
- Podatności niewidoczne z zewnątrz, np. SQLi w ścieżkach wewnętrznych
- Składowanie haseł i sekretów: zmienne środowiskowe, konfiguracja, logi
- Zależności npm, NuGet, pip i Composer ze znanymi CVE
- Obsługa błędów i logowanie pod kątem bezpieczeństwa
- Wynik
- Podatności z dokładnym miejscem w kodzie i gotową poprawką
- Dla kogo
- Producenci oprogramowania, systemy medyczne i finansowe, due diligence przed przejęciem
-
Compliance Assessment
Weryfikacja zgodności z konkretną normą lub regulacją - bez pełnego zakresu testów penetracyjnych.
Indywidualnie wycena zależy od liczby wymagań i systemów
- DORA: zarządzanie ryzykiem ICT (art. 8-10), testy odporności i TLPT (art. 24-27)
- NIS2/KSC: środki zarządzania ryzykiem, obsługa incydentów, łańcuch dostaw
- OWASP ASVS 5.0: weryfikacja na poziomie L1, L2 lub L3
- RODO art. 32: adekwatność środków technicznych
- Wynik
- Lista wymagań spełnionych i niespełnionych z rekomendacjami
- Dla kogo
- Podmioty nadzorowane przez KNF, objęte DORA lub NIS2/KSC
Każdą ofertę przygotowujemy indywidualnie. Czynniki, od których zależy cena, opisujemy w cenniku testów penetracyjnych.
06Metodyka
Metodyka: standardy, poziomy testów i ocena ryzyka
Standardy
- OWASP WSTG v4.2 - główna metodyka testów aplikacji webowych (12 kategorii testów),
- PTES - ramy procesu: od ustaleń przedtestowych po raport,
- NIST SP 800-115 - testy infrastruktury i sieci,
- OWASP Top 10:2025, API Security Top 10 2023, ASVS 5.0, MASVS 2.1 - klasyfikacja ryzyk i wymagania weryfikacyjne,
- CWE - identyfikacja klas słabości.
Standardy wymieniamy, bo z nich korzystamy - nie sugerujemy certyfikacji ani partnerstwa z organizacjami, które je wydają.
Ocena ryzyka
Każdą podatność oceniamy w CVSS 3.1 (na życzenie także w CVSS 4.0) i dodajemy kontekstowy Risk Rating: ta sama luka znaczy co innego w systemie płatności, a co innego w wewnętrznym narzędziu bez danych osobowych. Ustalenia mapujemy na wymagania DORA, NIS2/KSC, RODO i ISO/IEC 27001.
Poziomy testów
- Poziom 1 - rekonesans, konfiguracja TLS, nagłówki HTTP, reflected XSS, enumeracja, błędy konfiguracji.
- Poziom 2 - IDOR, eskalacja uprawnień, SQL injection, XXE, CSRF, kryptografia, logika biznesowa.
- Rewizja kodu - logika autoryzacji, sekrety, zależności ze znanymi CVE.
W Audycie Kompleksowym wykonujemy minimum 67 testów w 12 kategoriach OWASP WSTG v4.2.
Łańcuch ataku
Pojedyncze podatności o średnim ryzyku często składają się w poważny scenariusz. W raporcie pokazujemy takie łańcuchy krok po kroku - jak na diagramie poniżej.
07Jak pracujemy
Jak wygląda współpraca przy pentestach
Sześć kroków od pierwszej rozmowy do retestu. Test zaczynamy dopiero po pisemnej zgodzie właściciela systemu i uzgodnieniu zasad.
-
Kwalifikacja i NDA
Krótka rozmowa o systemie, celach i wymaganiach. Na życzenie najpierw podpisujemy NDA.
-
Zakres i zasady testów
Pisemna zgoda właściciela systemu, lista celów, konta testowe, okna czasowe i kontakty awaryjne.
-
Testy
Testy według uzgodnionej metodyki, w trybie nieinwazyjnym i w ustalonych oknach czasowych.
-
Raport
Każda podatność z dowodem, oceną CVSS, kontekstem biznesowym i rekomendacją naprawy.
-
Prezentacja wyników
Omówienie wyników z zespołem technicznym oraz krótki briefing dla zarządu.
-
Retest
Po naprawach sprawdzamy każdą podatność ponownie i aktualizujemy raport.
08Co dostajesz
Raport, na którym można polegać
Raport piszemy dla dwóch odbiorców: zespołu, który naprawia, i zarządu, który decyduje o priorytetach i budżecie.
01
Executive Summary
Podsumowanie dla zarządu językiem biznesowym: najważniejsze ryzyka, ich skutki i priorytety.
02
Część black box i grey box
Wyniki testu bez dostępu i z kontami testowymi opisane rozdzielnie - widać, co grozi z zewnątrz, a co po zalogowaniu.
03
Dowody techniczne
Dosłowny wynik poleceń i zapytań, bez parafraz - Twój zespół może odtworzyć każdy krok.
04
Rekomendacje naprawy
Konkretna propozycja naprawy każdej podatności, a przy rewizji kodu - gotowa poprawka.
05
Harmonogram remediacji
Zalecane terminy usunięcia podatności według poziomu ryzyka.
06
Wersje PL i EN
Raport po polsku i angielsku - dla zespołów i zarządów międzynarodowych.
| ID | Podatność | Poziom | CVSS 3.1 | Zalecany termin naprawy |
|---|---|---|---|---|
| WEB-01 | SQL injection w parametrze wyszukiwania (potwierdzone bezpiecznym PoC) | Critical | 9.1 | 14 dni |
| API-02 | Odczyt danych dowolnego klienta przez identyfikator w adresie (IDOR) | High | 7.5 | 30 dni |
| WEB-03 | Stored XSS w polu komentarza widocznym dla administratora | Medium | 5.4 | 90 dni |
| API-04 | Brak limitu żądań przy wysyłaniu plików | Medium | 4.3 | 90 dni |
| WEB-05 | Cookie sesji bez atrybutu Secure | Low | 3.1 | 180 dni |
Przykład pełnego opisu podatności - z wektorem CVSS, dowodem i rekomendacją - pokazujemy na stronie testów penetracyjnych aplikacji webowych.
09Bezpieczeństwo testów
Gwarancja nieinwazyjności
Test ma pokazać ryzyko, a nie je zrealizować. Te zasady obowiązują w każdym projekcie, także na produkcji.
Bez modyfikacji danych
Nie zmieniamy danych, baz, plików ani kont użytkowników.
Bez DoS i testów obciążeniowych
Nie wykonujemy testów obciążeniowych ani ataków DoS/DDoS.
Bez trwałych zmian
Nie zostawiamy webshelli, backdoorów ani innych trwałych zmian w systemie.
Bezpieczne Proof of Concept
Podatność potwierdzamy minimalnym, bezpiecznym dowodem - bez wykorzystywania jej dalej, niż trzeba.
Brute-force tylko za zgodą
Próby odgadywania haseł - najwyżej 20 i wyłącznie za pisemną zgodą.
10Cena
Ile kosztuje pentest
Cena testu penetracyjnego zależy od zakresu: liczby funkcji i ról użytkowników, liczby endpointów API, wybranego podejścia (black, grey lub white box), środowiska i tego, czy w umowie jest retest. Nie publikujemy cennika z gotowymi kwotami - każdą ofertę przygotowujemy po krótkiej rozmowie zakresowej, dopasowaną do systemu i wymagań regulacyjnych. Pełną listę czynników i checklistę zapytania znajdziesz w cenniku testów penetracyjnych.
11Gdzie działamy
Testy penetracyjne w całej Polsce
Zespół testów bezpieczeństwa pracuje z biura we Wrocławiu. Aplikacje webowe, API, aplikacje mobilne i chmurę testujemy zdalnie, a test sieci wewnętrznej prowadzimy przez VPN, z komputera przygotowanego w Twojej sieci albo na miejscu - w Twojej siedzibie, w każdym mieście w Polsce.
Opisaliśmy, jak prowadzimy testy dla firm we Wrocławiu, w Warszawie, w Krakowie, w Katowicach, w Poznaniu i w Gdańsku.
Najczęściej zadawane pytania
Czym różni się test penetracyjny od skanu podatności?
Skaner automatycznie porównuje system z bazą znanych błędów i zwykle zwraca długą listę potencjalnych problemów, w tym wiele fałszywych alarmów. Test penetracyjny prowadzi człowiek - każde znalezisko weryfikuje, próbuje je bezpiecznie wykorzystać i łączy podatności w łańcuchy ataku. Dzięki temu wykrywa błędy logiki biznesowej i autoryzacji, których skaner nie widzi, a raport zawiera tylko potwierdzone ustalenia z dowodami.
Czy testujecie na środowisku produkcyjnym?
Możemy testować produkcję albo środowisko testowe - decyzję podejmujemy razem przy ustalaniu zakresu. Na produkcji pracujemy w trybie nieinwazyjnym: bez modyfikacji danych, bez testów obciążeniowych i w uzgodnionych oknach czasowych. Testy grey box z kontami testowymi najlepiej prowadzić na środowisku testowym, które jest kopią produkcji, bo wtedy możemy sprawdzić więcej scenariuszy bez ryzyka dla prawdziwych danych.
Ile trwa test penetracyjny?
Czas zależy od zakresu - liczby funkcji, ról użytkowników, endpointów API i środowisk - oraz od wybranego podejścia. Termin rozpoczęcia i czas testów podajemy w ofercie po krótkiej rozmowie zakresowej. Na zapytanie odpowiadamy w ciągu 24 godzin w dni robocze.
Co musimy przygotować przed testem?
Pisemną zgodę właściciela systemu na test, listę celów (adresy, aplikacje, zakresy IP), osobę kontaktową i kontakt awaryjny, a przy testach grey box także konta testowe dla każdej roli. Pomaga dokumentacja: specyfikacja API, opis ról i uprawnień, informacja o ochronie typu WAF. Szczegółową listę znajdziesz w cenniku pentestów.
Czy test może zatrzymać działanie systemu?
Ryzyko ograniczamy do minimum. Nie wykonujemy testów DoS ani obciążeniowych, nie modyfikujemy danych, a podatności potwierdzamy bezpiecznymi Proof of Concept. Przed testem ustalamy okna czasowe i kontakt awaryjny, a w razie niespodziewanego zachowania systemu natychmiast wstrzymujemy prace.
Czy podpisujecie NDA?
Tak. Każdy projekt prowadzimy na podstawie umowy i NDA, a na życzenie podpisujemy rozszerzone NDA jeszcze przed rozmową o szczegółach systemu.
Co się dzieje z podatnościami po raporcie?
Raport zawiera rekomendację naprawy każdej podatności i zalecany termin usunięcia według poziomu ryzyka: Critical 14 dni, High 30 dni, Medium 90 dni, Low 180 dni. Po naprawach wykonujemy retest - sprawdzamy każdą podatność ponownie z nowym dowodem technicznym i aktualizujemy raport. W Audycie Kompleksowym retest jest częścią umowy.
Czy test penetracyjny spełnia wymogi NIS2 i ustawy o KSC?
Wspiera je, ale ich nie wyczerpuje. Znowelizowana ustawa o KSC wymaga od podmiotów kluczowych i ważnych m.in. testowania systemu informacyjnego i oceny skuteczności środków bezpieczeństwa - pentest jest na to dobrym dowodem. Nie jest jednak audytem bezpieczeństwa z art. 15 ustawy, który obejmuje cały system zarządzania bezpieczeństwem informacji i który musi przeprowadzić niezależny audytor. Więcej o audycie i przygotowaniu do niego: audyt NIS2/KSC.
Źródła
- Ustawa z dnia 23 stycznia 2026 r. o zmianie ustawy o krajowym systemie cyberbezpieczeństwa oraz niektórych innych ustaw (Dz.U. 2026 poz. 252) - art. 8 i art. 15 ustawy o KSC ()
- Rozporządzenie (UE) 2022/2554 w sprawie operacyjnej odporności cyfrowej sektora finansowego (DORA) - art. 24-27 ()
- Rozporządzenie (UE) 2016/679 (RODO) - art. 32 ()
- Ustawa z dnia 6 czerwca 1997 r. - Kodeks karny (tekst jednolity Dz.U. 2025 poz. 383 ze zm.) - art. 267-269c ()
- OWASP Web Security Testing Guide (WSTG) v4.2 ()
- NIST SP 800-115 - Technical Guide to Information Security Testing and Assessment ()
- FIRST - Common Vulnerability Scoring System (CVSS) v3.1 i v4.0 ()
Powiązane usługi
Zgodność · NIS2 / KSC
Audyt NIS2 / KSC
Audyt NIS2 i KSC: kogo obejmuje nowelizacja, terminy 3.04.2027 i 3.04.2028, obowiązki, audyt z art. 15 i kary. Audyt zerowy, wdrożenie, pentesty.
Zgodność · DORA
DORA i TLPT
DORA (rozporządzenie 2022/2554): kogo dotyczy, obszary wymagań, testy z art. 24-25 i TLPT, ryzyko ICT i wymagania wobec dostawców. Testy i ocena zgodności.
Oprogramowanie dedykowane · Security by design
Security by design
Security by design w praktyce: model zagrożeń, wymagania OWASP ASVS, przegląd kodu, SAST i SCA w CI/CD, pentest przed wydaniem i zarządzanie podatnościami.