Pentest aplikacji mobilnej - co sprawdzamy w Androidzie i iOS (OWASP MASVS)

Aplikacja webowa działa na Waszym serwerze, a użytkownik widzi tylko to, co mu wyślecie. Z aplikacją mobilną jest odwrotnie: cały kod klienta leży u użytkownika. Plik APK albo IPA można zdekompilować, a narzędzia takie jak Frida pozwalają podmienić dowolną funkcję w działającej aplikacji, np. tę, która sprawdza, czy użytkownik ma uprawnienia do danego ekranu.

Z tego wynika najważniejsza zasada, którą sprawdzamy w każdym teście: zabezpieczenie zrobione tylko w aplikacji można obejść. Liczy się to, co weryfikuje serwer.

Według czego testujemy: OWASP MASVS i MASTG

Punktem odniesienia jest projekt OWASP Mobile Application Security, na który składają się trzy dokumenty:

• MASVS - standard wymagań bezpieczeństwa. Dzieli je na osiem obszarów: przechowywanie danych, kryptografia, uwierzytelnianie, komunikacja sieciowa, interakcja z platformą, jakość kodu, odporność na analizę i prywatność.
• MASTG - przewodnik testowania, czyli konkretne techniki i testy dla Androida i iOS. W czerwcu 2026 ukazała się wersja 2.0, pierwsza stabilna po dużej przebudowie.
• MASWE - katalog typowych słabości aplikacji mobilnych, od sierpnia 2026 w stabilnej wersji 1.0. Łączy wymagania MASVS z testami z MASTG.

Dla Was praktyczna korzyść jest taka, że każde znalezisko w raporcie da się powiązać z konkretnym wymaganiem standardu. Łatwiej wtedy uzasadnić poprawkę przed zespołem i porównać wyniki kolejnych testów.

Dane zostawione na urządzeniu

Telefony giną, są kradzione, oddawane do serwisu i sprzedawane. Sprawdzamy, co zostaje w pamięci aplikacji i czy da się to odczytać:

• Tokeny i hasła poza bezpiecznym magazynem. Do przechowywania sekretów służą Keychain na iOS i Keystore na Androidzie. Regularnie widzimy tokeny sesji zapisane w zwykłych ustawieniach aplikacji albo w lokalnej bazie SQLite.
• Logi. Komunikaty diagnostyczne zostawione z czasu developmentu, w których lądują odpowiedzi serwera razem z danymi osobowymi.
• Pamięć podręczna i pliki tymczasowe. Pobrane dokumenty, zdjęcia, zrzuty ekranu robione przez system przy przełączaniu aplikacji.
• Kopie zapasowe. Czy dane aplikacji trafiają do kopii urządzenia i czy da się je z niej wyciągnąć.
• Stan po wylogowaniu. Czy wylogowanie faktycznie usuwa dane i unieważnia sesję po stronie serwera, czy tylko przełącza ekran na logowanie.

Co jest zaszyte w pliku instalacyjnym

Analiza statyczna zaczyna się od rozpakowania pakietu i przejrzenia kodu oraz zasobów. Szukamy rzeczy, które nie powinny tam trafić:

• Klucze API i sekrety. Klucze do usług płatnych, map, wysyłki SMS, czasem dane dostępowe do chmury z uprawnieniami do zapisu. Wszystko, co jest w aplikacji, jest de facto publiczne.
• Adresy środowisk testowych. Serwer deweloperski albo panel administracyjny, który miał być dostępny tylko wewnętrznie, a jest osiągalny z internetu i zwykle słabiej zabezpieczony niż produkcja.
• Ukryte funkcje. Ekrany debugowania, przełączniki funkcji, tryby „dla testerów” aktywowane prostym parametrem.
• Biblioteki zewnętrzne. Przestarzałe SDK ze znanymi podatnościami i biblioteki analityczne wysyłające więcej danych, niż deklaruje polityka prywatności.

Komunikacja z serwerem

Przechwytujemy ruch między aplikacją a backendem i sprawdzamy, czy jest poprawnie szyfrowany, czy aplikacja akceptuje fałszywy certyfikat i czy nie przesyła więcej danych, niż potrzebuje do wyświetlenia ekranu.

Osobna sprawa to przypinanie certyfikatów (certificate pinning), które utrudnia podsłuch nawet na przejętym urządzeniu. Warto je mieć, ale trzeba wiedzieć, co daje: chroni użytkownika przed atakiem w sieci, a nie serwer przed napastnikiem, który kontroluje własny telefon. W teście i tak je obchodzimy, żeby dostać się do API. Jeśli bezpieczeństwo backendu opiera się na tym, że „nikt nie zobaczy zapytań”, to właśnie znaleźliśmy problem.

Interakcja z systemem: deeplinki i komponenty

Aplikacja nie działa w próżni. Otwiera linki, przyjmuje dane od innych aplikacji i udostępnia im swoje. To tutaj platformy najbardziej się różnią i tutaj często pojawiają się błędy:

• Deeplinki. Link w mailu albo na stronie otwiera konkretny ekran aplikacji. Sprawdzamy, czy da się nim wykonać akcję bez potwierdzenia, przekazać złośliwe parametry albo przejąć link przeznaczony dla innej aplikacji.
• Wyeksportowane komponenty na Androidzie. Aktywności, serwisy i dostawcy treści dostępni dla innych aplikacji na telefonie, czasem bez żadnej kontroli, kto z nich korzysta.
• WebView. Strona wyświetlana wewnątrz aplikacji z dostępem do jej funkcji przez mostek JavaScript. Jeśli da się w niej załadować obcą treść, napastnik dostaje te same możliwości.

Backend, czyli tam, gdzie jest najwięcej znalezisk

Najpoważniejsze problemy w testach aplikacji mobilnych rzadko siedzą w samej aplikacji. Siedzą w API, z którym się łączy. Typowy scenariusz: aplikacja pokazuje użytkownikowi tylko jego zamówienia, ale serwer zwróci dowolne zamówienie, jeśli zmienić numer w zapytaniu. W interfejsie tego nie widać, więc nikt tego nie sprawdził.

Inne częste przypadki to ceny i rabaty liczone w aplikacji i przyjmowane przez serwer bez weryfikacji, limity sprawdzane tylko po stronie klienta oraz stare wersje API, które dalej działają, choć aktualna aplikacja już z nich nie korzysta. Szerzej opisujemy to we wpisach jak testować REST API i OWASP API Security Top 10.

Dlatego zawsze rekomendujemy, żeby backend był w zakresie testu. Sama aplikacja bez serwera daje niepełny obraz.

Root, jailbreak i zaciemnianie kodu

Wiele aplikacji, zwłaszcza finansowych, wykrywa zrootowane urządzenia, utrudnia debugowanie i zaciemnia kod. Sprawdzamy, czy te mechanizmy działają i ile czasu zajmuje ich obejście. Zwykle niewiele.

To nie znaczy, że są bezużyteczne. Podnoszą koszt ataku i odsiewają przypadkowych napastników. Problem pojawia się wtedy, gdy zastępują prawdziwe zabezpieczenia, np. gdy jedynym powodem, dla którego nikt nie odczytał tokena z pamięci, ma być wykrywanie roota.

Android i iOS: jeden test czy dwa?

Dwa. Platformy różnią się sposobem przechowywania danych, modelem uprawnień, komunikacją między aplikacjami i narzędziami do analizy. Aplikacja napisana we Flutterze czy React Native ma wspólny kod, ale po zbudowaniu każda wersja zachowuje się inaczej i każdą trzeba sprawdzić osobno.

Wspólny jest zwykle backend, więc przy teście obu platform tej części nie robimy dwa razy.

Jak się przygotować

• przygotujcie wersję testową aplikacji: plik APK, dostęp przez TestFlight albo inny kanał testowy, najlepiej bez zaciemniania kodu, jeśli chcecie dokładniejszej analizy,
• załóżcie co najmniej dwa konta testowe w każdej roli, żeby dało się sprawdzić dostęp do cudzych danych,
• ustalcie, które środowisko backendu testujemy i czy są na nim prawdziwe dane,
• jeśli możecie, udostępnijcie dokumentację API albo kod źródłowy, bo skraca to analizę i pozwala zejść głębiej.

Aplikacji nie musi jeszcze być w sklepie. Test przed publikacją to najlepszy moment, bo poprawka nie wymaga wtedy wydawania aktualizacji i czekania, aż użytkownicy ją zainstalują. Ogólną listę kroków przed każdym testem opisujemy we wpisie jak przygotować firmę do pentestu, a o tym, co dostaniecie na końcu, we wpisie jak czytać raport z pentestu.

Zakres i przebieg testu opisujemy na stronie testów penetracyjnych aplikacji mobilnych.