Test penetracyjny aplikacji webowych i API

Aplikacja bywa jedynym miejscem, w którym dane wychodzą poza sieć. Sprawdzam, czy da się je stamtąd wyprowadzić cudzymi uprawnieniami.

Dla kogo jest ten test

Dla organizacji, które mają własną aplikację — portal klienta, panel do zamawiania, system wewnętrzny, publiczne API dla partnerów. Test jest potrzebny zarówno przed udostępnieniem aplikacji na zewnątrz, jak i po zmianach: przebudowa modułu uwierzytelniania albo dodanie API potrafi cofnąć zabezpieczenia wypracowane wcześniej.

Test przydaje się też, gdy aplikacja przechodzi audyt zgodności — kod dostarcza dowodu technicznego, którego nie zastąpi przegląd dokumentacji.

Co dokładnie sprawdzam

kontrolę dostępu: czy da się zobaczyć lub zmienić cudze dane, zmieniając identyfikator albo żądając zasobu bezpośrednio,
uwierzytelnianie i zarządzanie sesją: trwałość sesji, wylogowanie, odświeżanie tokenów,
OWASP Top 10: wstrzykiwanie zapytań, wadliwa walidacja na serwerze, błędy autoryzacji i konfiguracji,
API REST i GraphQL: autoryzacja na poziomie punktów końcowych, nadmiarowe dane w odpowiedziach, zapytania pozwalające odczytać to, czego nie powinny,
logikę biznesową: czy da się obejść limity, powtórzyć operację wielokrotnie, ominąć etap płatności lub zatwierdzenia,
obsługę plików: przesyłanie, walidację typów, przechowywanie i dostęp do nich,
nagłówki i konfigurację warstwy webowej pod kątem polityki bezpieczeństwa treści.

Jak wygląda praca krok po kroku

Ustalenie zakresu: adresy, role w aplikacji, środowisko testowe albo produkcyjne, konta dla testera, granice ingerencji w dane.
Rozpoznanie: mapowanie funkcji, punktów końcowych API i przepływów danych z perspektywy każdej roli.
Weryfikacja: potwierdzenie podatności z dowodem w postaci żądania i odpowiedzi, z oceną wpływu na dane i dostępność.
Ocena wykrywalności: czy Państwa monitoring odnotowuje nietypowe żądania.
Raport i omówienie z zespołem programistów.

Czego ten wariant nie obejmuje

Nie testuję aplikacji mobilnych jako osobnego kanału (mogę to objąć dodatkowym zakresem), nie robię przeglądu kodu źródłowego w trybie białej skrzynki ani nie prowadzę testów wydajnościowych. Nie zmieniam trwale danych w środowisku produkcyjnym: operacje zapisujące wykonuję na koncie testowym i w zakresie, który Państwo zatwierdzą. Nie naprawiam znalezionych błędów — dostarczam opis i rekomendację.

Co Państwo dostają po zakończeniu

Raport techniczny z podziałem na funkcje aplikacji: każde ustalenie z żądaniem i odpowiedzią, opisem wpływu, priorytetem i rekomendacją. Osobna sekcja dotyczy API, jeśli w zakresie jest — z listą punktów końcowych wymagających poprawy autoryzacji. W raporcie wykonawczym ryzyko jest przetłumaczone na skutki: jakie dane mógłby odczytać lub zmienić atakujący i komu to zaszkodzi.

Czego szukamy najczęściej

W aplikacjach, które testuję, trzy problemy powtarzają się najczęściej. Pierwszy to kontrola dostępu na poziomie obiektu: funkcja sprawdza, czy użytkownik jest zalogowany, ale nie sprawdza, czy ten konkretny rekord należy do niego. Drugi — autoryzacja w API: front ukrywa niedostępne operacje, ale punkt końcowy przyjmuje je od każdego, bo zabezpieczenie zostało tylko w warstwie prezentacji. Trzeci to logika biznesowa, której nie da się wykryć skanerem: rabaty, wielokrotne użycie kodu, kolejność kroków, którą można przestawić. Dlatego test aplikacji wymaga rozumienia procesu, a nie tylko listy sygnatur.

Ile trwa i ile kosztuje

Wycena zależy od liczby aplikacji, liczby ról oraz liczby punktów końcowych API — nie od liczby stron, bo te można policzyć automatycznie. Stawka 250 zł netto za godzinę, widełki ±20%; pełny model i kwoty w sekcji wyceny.

Wariant	Środowisko	Czas	Kwota netto (±20%%)
Web	1 aplikacja, 2 role	44 h	8 800 – 13 200 zł
Web	2 aplikacje, 3 role, 50 endpointów API	70 h	14 000 – 21 000 zł

Jeśli aplikacja ma środowisko testowe z reprezentatywnymi danymi, test jest krótszy i bezpieczniejszy. Brak takiego środowiska wydłuża zakres, bo część operacji trzeba zaplanować ostrożniej na produkcji.

Powiązane warianty

Test aplikacji pokazuje, co da się zrobić przez interfejs i API. Gdy aplikacja korzysta z domeny, warto objąć także Active Directory, a gdy jest wystawiona w sieci wewnętrznej — test sieci wewnętrznej. Osobno opisuję scenariusz dnia zero.

Pytania o ten wariant

Czy test aplikacji zastępuje przegląd kodu źródłowego?

Nie. Test sprawdza aplikację uruchomioną, czyli to, co faktycznie widzi i może wykorzystać atakujący — także warstwy, do których kod nie ma dostępu, na przykład konfigurację serwera. Przegląd kodu pokazuje intencje programisty i znajduje błędy w miejscach trudno dostępnych z zewnątrz. Oba podejścia się uzupełniają.

Czy test działa na produkcji, czy potrzebne jest środowisko testowe?

Najlepiej oba: produkcja pokazuje realną konfigurację, a środowisko testowe pozwala bezpiecznie sprawdzić operacje zapisujące. Jeśli jest tylko produkcja, test prowadzę z ograniczeniami — na koncie testowym i bez trwałych zmian w danych, które Państwo zatwierdzili.

Czy sprawdzają Państwo też API, którego używają nasi partnerzy?

Jeśli jest w zakresie — tak, i zwykle to najbardziej wartościowa część testu. API bywa udostępniane szerzej niż interfejs, a kontrola dostępu sprawdzana jest wyłącznie w przeglądarce. Test obejmuje wtedy autoryzację punktów końcowych, nadmiarowe dane w odpowiedziach i zachowanie przy nieprawidłowych parametrach.

Kiedy powinno się powtórzyć test?

Po zmianach w uwierzytelnianiu, po dodaniu nowego modułu albo API oraz po większej przebudowie. Retest samego zakresu poprawek jest tańszy od pełnego testu i wystarcza, gdy zmiany dotyczyły ustalonych wcześniej punktów.

Pozostałe pytania — o czas trwania, dane z testu, podstawy prawne i koszt — zebrałem w sekcji pytania i odpowiedzi. Orientacyjne kwoty i model wyliczenia są w wycenie.