Testy aplikacji mobilnych obejmujące aplikację, urządzenie i backend.

Nie. Możemy przeprowadzić test black-box na pliku APK/IPA. Dostęp do kodu zwiększa jednak pokrycie i ułatwia analizę przyczyn.

Rekomendujemy objęcie zakresem API, ponieważ wiele krytycznych błędów mobilnych znajduje się po stronie zaufania backendu.

Tak, jeżeli jest to potrzebne do kontroli komunikacji i dozwolone w zakresie. Sama obecność pinningu nie zastępuje bezpieczeństwa API.

Zależy od platformy i sposobu dystrybucji. Ustalamy wymagania techniczne przed rozpoczęciem.

Tak. Szukamy kluczy API, tokenów, haseł, sekretów i danych dostępowych w kodzie, zasobach, logach, kopiach zapasowych i pipeline. Sprawdzamy również możliwość nadużycia po wyodrębnieniu sekretu z aplikacji.

Tak. Analizujemy biblioteki, SDK reklamowe i analityczne, proces budowania, podpisy, aktualizacje oraz zależności pochodzące z zewnętrznych repozytoriów. Wskazujemy komponenty podatne i zbierające nadmiarowe dane.

Tak. Testujemy logowanie, biometrię, MFA, tokeny, odświeżanie sesji, role, funkcje ukryte w kliencie i backendowe kontrole dostępu. Manipulacja aplikacją nie może zastępować autoryzacji po stronie serwera.

Tak. Sprawdzamy dane z deep linków, intentów, schowka, plików, QR, WebView, API i mechanizmów udostępniania. Test obejmuje injection, path traversal, niebezpieczne URI i błędne parsowanie odpowiedzi.

Tak. Weryfikujemy TLS, certificate pinning, hostname verification, cleartext traffic, proxy, WebSocket, niestandardowe protokoły i zachowanie przy błędach certyfikatu. Analizujemy również dane wysyłane do usług trzecich.

Tak. Sprawdzamy minimalizację danych, zgody, identyfikatory urządzenia, telemetrykę, analitykę, logi, screenshoty i dane pozostające po wylogowaniu. Wyniki opisują techniczny przepływ danych, nie tylko deklaracje interfejsu.

Tak. Oceniamy odporność na modyfikację, repackaging, hooking, debugging, emulatory, root/jailbreak i podmianę kodu. Ochronę binarną traktujemy jako warstwę utrudniającą, a nie zastępstwo kontroli serwerowych.

Tak. Analizujemy manifest, exported components, entitlements, ATS/network security config, backup, debug, uprawnienia, Universal Links i App Links. Sprawdzamy także konfigurację usług push i backendu mobilnego.

Tak. Badamy Keychain/Keystore, SQLite, SharedPreferences, pliki, cache, logi, clipboard, screenshoty i kopie zapasowe. Weryfikujemy dane dostępne po utracie urządzenia, root/jailbreak lub przez inną aplikację.

Tak. Sprawdzamy algorytmy, tryby pracy, IV, generatory losowe, klucze zaszyte w aplikacji, własne schematy szyfrowania i prawidłową walidację podpisów. Oceniamy, czy kryptografia faktycznie chroni przed założonym przeciwnikiem.

Tak. Sprawdzamy przejęcie schematu URL, błędne hosty, open redirect, JavaScript bridges, file access, intent injection i możliwość uruchomienia chronionej funkcji z innej aplikacji lub strony WWW.

Tak, jeżeli jest to potrzebne do analizy runtime. Używamy kontrolowanego środowiska do instrumentacji, obserwacji pamięci, omijania pinningu i weryfikacji założeń; raport rozróżnia wymagany poziom dostępu atakującego.

Tak, jeśli znajduje się w uzgodnionym zakresie. Bez testu API nie można wiarygodnie ocenić autoryzacji, logiki biznesowej i odporności na zmodyfikowanego klienta, dlatego rekomendujemy łączny zakres mobile plus API.

Możemy rozpocząć od wersji dystrybucyjnej, APK, AAB lub IPA. Kod źródłowy, build debug i dokumentacja architektury zwiększają pokrycie oraz ułatwiają wskazanie dokładnej przyczyny i poprawki.

Test jednej platformy, Android albo iOS, zaczyna się od 3 000 PLN netto. Ostateczna cena zależy od liczby platform, funkcji, ról, mechanizmów ochronnych i zakresu backendu. Wspólny zakres Android, iOS i API potwierdzamy w ofercie, a wycenę przygotowujemy zwykle w około 24 godziny.

Tak, ponieważ platformy różnią się mechanizmami bezpieczeństwa, konfiguracją, pamięcią, linkami, WebView i dystrybucją. Część logiki i API może być wspólna, ale binaria oraz zachowanie runtime należy zweryfikować oddzielnie. Zakres łączony pozwala ograniczyć powtarzanie testów backendu.

Test funkcjonalny sprawdza, czy aplikacja działa zgodnie z wymaganiami. Pentest zakłada zmodyfikowane urządzenie i klienta, analizuje binarium, pamięć, transmisję, komponenty systemowe oraz możliwość bezpośredniego użycia API. Automatyczny skaner nie potwierdzi większości błędów autoryzacji i logiki biznesowej.

Należy przekazać APK, AAB lub IPA albo dostęp do wersji dystrybucyjnej, konta testowe dla kilku ról, opis backendu i głównych procesów. Przydatny jest build debug lub testowy, dokumentacja deep linków i lista mechanizmów pinningu. Dane produkcyjne nie są potrzebne do przygotowania wyceny.

Wersja sklepowa pokazuje rzeczywistą konfigurację użytkownika, podpisy i zabezpieczenia binarne. Build testowy ułatwia diagnostykę, instrumentację i dokładne wskazanie przyczyny. Najlepsze pokrycie daje test wersji zbliżonej do produkcyjnej z kontrolowanym dostępem do artefaktów pomocniczych.

Tak. Zakres dostosowujemy do danych i procesów: płatności, autoryzacji transakcji, danych medycznych, zakupów, kuponów, powiadomień i integracji urządzenia. W branżach regulowanych szczególnie ważne są prywatność, odporność backendu i wiarygodne dowody dla zespołu naprawczego.

Może dostarczyć technicznej weryfikacji zabezpieczeń aplikacji i API oraz planu naprawczego wspierającego zgodność. Zakres i raport możemy mapować do właściwych kontroli klienta. Sam pentest nie zastępuje pełnego audytu regulacyjnego ani pozostałych obowiązków organizacji.

Raport powinien rozróżniać platformę, wersję, urządzenie, wymagany poziom dostępu atakującego i wpływ na backend. Każda podatność powinna mieć CVSS, kroki reprodukcji, dowód, wpływ, rekomendację oraz test zamknięcia. Ważne jest wskazanie, które zabezpieczenia muszą znajdować się po stronie serwera.