01
Tożsamość i autoryzacja
Weryfikujemy granice między użytkownikami, rolami i tenantami.
- IDOR/BOLA i eskalacja uprawnień
- Sesje, MFA, reset hasła i odzyskiwanie konta
- OAuth/OIDC, SSO, tokeny i klucze API
OFFENSIVE SECURITY / WEB · API
Testy penetracyjne aplikacji webowych i API
Sprawdzamy nie tylko pojedyncze endpointy, lecz całą drogę od wejścia do wpływu na dane, pieniądze i proces biznesowy.
Automatyczny skaner wykryje część błędów technicznych. My testujemy również relacje między rolami, tenantami, funkcjami i integracjami — miejsca, w których najczęściej powstają podatności o realnym znaczeniu.
WEB · API · MOBILE
Powierzchnia testów
BLACK · GREY · WHITE
Model dostępu
MANUAL FIRST
Walidacja znalezisk
RETEST
Weryfikacja poprawek
01 / KONTEKST DECYZJI
Kiedy ten test ma sens
- 01Przed uruchomieniem nowej aplikacji, API albo istotnej funkcji.
- 02Przed audytem klienta, rundą finansowania lub wejściem na regulowany rynek.
- 03Po zmianie architektury, uwierzytelniania, płatności albo modelu uprawnień.
- 04Gdy zespół potrzebuje dowodu bezpieczeństwa, a nie kolejnego eksportu ze skanera.
02 / POWIERZCHNIA TESTU
Co rzeczywiście sprawdzamy
02
Logika biznesowa
Odtwarzamy sposób działania realnego napastnika, a nie tylko listę OWASP.
- Obejście limitów, stanów i akceptacji
- Manipulacja ceną, kolejnością i własnością zasobów
- Race conditions i nadużycie procesów
03
Warstwa techniczna
Testujemy wejścia, integracje i przepływy danych w pełnym kontekście.
- Injection, SSRF, XSS, deserializacja i upload
- GraphQL, REST, webhooki i integracje zewnętrzne
- Sekrety, błędy konfiguracji i ekspozycja danych
03 / REALIZACJA
Jak prowadzimy test
- BR / 01
Zakres i rules of engagement
Ustalamy aktywa, konta testowe, wyłączenia, okna prac i kanał pilnego zgłaszania krytycznych ustaleń.
- BR / 02
Mapowanie aplikacji
Budujemy model ról, danych, funkcji, API i granic zaufania, zanim zaczniemy łączyć podatności.
- BR / 03
Kontrolowana eksploatacja
Potwierdzamy wpływ minimalnym, bezpiecznym dowodem. Nie pobieramy danych, których nie potrzebujemy do walidacji.
- BR / 04
Raport, omówienie i retest
Przekazujemy warstwę zarządczą i techniczną, omawiamy poprawki z zespołem i weryfikujemy ich skuteczność.
04 / STANDARD DOWODU
Granica tenantów złamana przez niespójną autoryzację API
MODEL ZNALEZISKA / BEZ DANYCH KLIENTA
Przykład pokazuje standard opisu: najpierw potwierdzony skutek, potem dowód, warunki i konkretna kontrola do wdrożenia.
To model formatu raportowania, nie opis projektu klienta ani deklaracja wykrycia konkretnej luki.
E-1
Żądanie konta A odwołuje się do zasobu konta B
E-2
Backend potwierdza sesję, lecz nie sprawdza własności zasobu
E-3
Minimalny PoC potwierdza odczyt jednego kontrolowanego rekordu
E-4
Naprawa obejmuje autoryzację obiektową i test regresyjny
05 / REZULTAT
Co otrzymuje zespół
01
Streszczenie ryzyka dla osób decyzyjnych
Element pakietu
02
Techniczne znaleziska z dowodem i warunkami odtworzenia
Element pakietu
03
Wpływ na dane i proces, priorytet oraz rekomendacja naprawcza
Element pakietu
04
Mapa przetestowanych obszarów i ograniczeń zakresu
Element pakietu
05
Sesja techniczna oraz raport z retestu
Element pakietu
01Ile trwa test aplikacji?+
Najczęściej od kilku dni do kilku tygodni. Czas zależy od liczby ról, endpointów, integracji i modelu dostępu. Wycena powstaje po krótkim scope callu.
02Czy test może odbyć się na produkcji?+
Tak, jeśli zakres i ryzyko na to pozwalają. Stosujemy limity, konta testowe i uzgodnione zasady. Scenariusze mogące zakłócić działanie przenosimy na staging.
03Czy sam raport wystarczy deweloperom?+
Raport zawiera dowody i zalecenia, ale standardem jest również techniczne omówienie. Zespół może zweryfikować założenia i uzgodnić bezpieczną poprawkę.
BR / NEXT STEP
Masz aplikację lub API do sprawdzenia?
Wyślij krótki opis architektury, liczby ról i planowanego terminu. Wrócimy z zakresem, założeniami i wyceną.
NDA · jasny zakres · bezpośrednia komunikacja