MobSF to darmowe narzędzie, które w kilka minut sprawdza aplikację na Androida lub iOS pod kątem typowych błędów bezpieczeństwa. Pokazujemy, jak czytać jego raport, jak włączyć go do procesu wydawania aplikacji i czego nie znajdzie.
CEO
03 lip 2026
Plik instalacyjny aplikacji mobilnej trafia do telefonów setek tysięcy osób. Każda z nich może go rozpakować i zajrzeć do środka. Jeśli programista zostawił tam klucz do bazy danych, adres testowego serwera albo hasło do zewnętrznej usługi, ktoś je w końcu znajdzie.
Automatyczne testy bezpieczeństwa aplikacji mobilnych z MobSF pozwalają wyłapać takie błędy, zanim aplikacja trafi do sklepu. MobSF, czyli Mobile Security Framework, to narzędzie open source, które analizuje plik aplikacji na Androida lub iOS i w kilka minut tworzy raport z listą problemów. Nie zastępuje audytu prowadzonego przez specjalistę, ale bardzo skutecznie usuwa najprostsze błędy.
MobSF rozwija społeczność skupiona wokół otwartego projektu na GitHubie. Według repozytorium MobSF projekt ma ponad 21 tys. gwiazdek i jest udostępniany na licencji GPL-3.0, co oznacza, że firma może go używać bezpłatnie, także w projektach komercyjnych.
Narzędzie wykonuje dwa rodzaje testów. Analiza statyczna sprawdza plik aplikacji bez jej uruchamiania: czyta kod, konfigurację i dołączone biblioteki. Analiza dynamiczna uruchamia aplikację na emulatorze i obserwuje, co robi w trakcie działania. To mobilne odpowiedniki podejść znanych z aplikacji webowych, czyli SAST, statycznej analizy kodu, i DAST, testowania działającej aplikacji. MobSF obsługuje aplikacje na Androida w formatach APK i AAB oraz aplikacje na iOS w formacie IPA. Nie ma znaczenia, czy powstały natywnie w Kotlinie i Swifcie, czy w React Native albo Flutterze. Analizowany jest gotowy plik, który trafia do sklepu.
Wyniki MobSF są powiązane z OWASP MASVS, czyli standardem wymagań bezpieczeństwa dla aplikacji mobilnych opracowanym przez fundację OWASP. Dzięki temu każde ostrzeżenie ma odniesienie do konkretnego wymagania, a raport łatwiej porównać z wymaganiami klienta czy audytora.
MobSF najczęściej uruchamia się z gotowego obrazu w Dockerze, czyli w kontenerze, który zawiera wszystko, czego narzędzie potrzebuje. Wystarczy jedno polecenie na komputerze programisty lub serwerze, a po chwili w przeglądarce otwiera się panel MobSF. Dalej jest prosto. Przeciąga się do panelu plik APK lub IPA, czeka od jednej do kilku minut, zależnie od wielkości aplikacji, i dostaje raport. Można go przejrzeć w przeglądarce albo pobrać jako PDF.
Do pierwszego przeglądu nie potrzeba więc żadnej konfiguracji. Pierwszy raport pokazuje zwykle kilkadziesiąt pozycji, z czego część to sprawy poważne, część drobiazgi, a część fałszywe alarmy. Sztuka polega na tym, żeby je od siebie odróżnić.
Raport ma kilkanaście sekcji. Nie wszystkie są równie ważne. Poniżej omawiamy te, na które w praktyce warto patrzeć najpierw.
Na górze raportu jest ocena w skali od 0 do 100. To szybki wskaźnik, przydatny głównie do porównywania kolejnych wersji tej samej aplikacji. Nie należy go traktować jak certyfikatu. Aplikacja z wynikiem 60 może być bezpieczniejsza od aplikacji z wynikiem 80, jeśli jej problemy dotyczą mniej istotnych obszarów.
MobSF wypisuje wszystkie uprawnienia, o które aplikacja prosi: dostęp do lokalizacji, kontaktów, aparatu, plików. Oznacza te, które uznaje za niebezpieczne. Tu często wychodzą uprawnienia dodane kiedyś na potrzeby funkcji, której już nie ma. W aplikacjach na Androida analizowany jest też plik konfiguracyjny aplikacji. MobSF sprawdza, czy aplikacja nie pozwala na tworzenie kopii zapasowych danych przez narzędzia deweloperskie, czy nie udostępnia swoich ekranów innym aplikacjom i czy wersja produkcyjna nie ma włączonego trybu debugowania. To błędy łatwe do naprawienia i łatwe do przeoczenia.
To sekcja, którą czytamy zawsze. MobSF szuka w aplikacji kluczy do usług zewnętrznych, tokenów, haseł i adresów, które nie powinny być publiczne.
Skala problemu jest duża. Według badania Cybernews z 2024 r., które objęło ponad 156 tys. aplikacji na iOS, 71% z nich zawierało co najmniej jeden zapisany na sztywno sekret, a średnio 5,2 na aplikację. Wśród nich były klucze do baz Firebase bez zabezpieczeń i klucze do płatności w Stripe, które pozwalają wykonywać operacje na koncie firmy. Nie każdy znaleziony klucz jest problemem. Klucz publiczny do mapy czy analityki z założenia trafia do aplikacji. Klucz prywatny do płatności czy bazy danych nigdy nie powinien. Ocena, który jest który, wymaga człowieka, ale MobSF wskazuje, gdzie szukać.
MobSF sprawdza, czy aplikacja wymusza szyfrowane połączenia, czy nie pozwala na połączenia bez szyfrowania z wybranymi serwerami i czy weryfikuje certyfikaty serwera. Wyjątki dodane na czas testów, na przykład zgoda na połączenie z serwerem testowym bez certyfikatu, często zostają w wersji produkcyjnej. Raport je pokazuje.
Ostatnia duża część to ostrzeżenia dotyczące kodu, na przykład słabe algorytmy szyfrowania albo zapisywanie danych w miejscach dostępnych dla innych aplikacji. MobSF wypisuje też biblioteki zewnętrzne i narzędzia śledzące użytkowników, tak zwane trackery, które aplikacja zawiera. To przydatne przy wypełnianiu informacji o prywatności wymaganych przez App Store i Google Play.
Analiza statyczna widzi tylko to, co jest zapisane w pliku. Część problemów wychodzi dopiero wtedy, gdy aplikacja działa: jakie dane wysyła na serwer, co zapisuje w pamięci telefonu, jak reaguje na zmodyfikowane odpowiedzi serwera. MobSF uruchamia aplikację na Androida w emulatorze i przechwytuje jej ruch sieciowy. Korzysta przy tym z Fridy, narzędzia, które pozwala podglądać i zmieniać działanie aplikacji w trakcie pracy. Tester klika po aplikacji, a MobSF zapisuje, jakie żądania wychodzą, jakie pliki powstają i jakie dane trafiają do logów. Tu często wychodzą sprawy, których nie widać w kodzie. Token logowania zapisany w niezaszyfrowanym pliku. Numer telefonu użytkownika wysyłany do zewnętrznej biblioteki analitycznej.
Dla iOS analiza dynamiczna jest trudniejsza, bo wymaga wirtualnych urządzeń Apple dostępnych przez płatną usługę Corellium. W praktyce aplikacje na iOS najczęściej sprawdza się w MobSF statycznie, a testy dynamiczne prowadzi specjalista na fizycznym urządzeniu.
Jednorazowy raport ma ograniczoną wartość. Aplikacja zmienia się co kilka tygodni, a nowy sekret może pojawić się w kodzie przy dowolnej zmianie. Dlatego najwięcej daje uruchamianie MobSF automatycznie przy każdym budowaniu aplikacji. MobSF udostępnia API, czyli interfejs do sterowania nim z innych programów. Potok CI/CD, który po każdej zmianie buduje aplikację, może wysłać gotowy plik do MobSF, pobrać raport i sprawdzić, czy nie pojawiły się nowe problemy o wysokim priorytecie. Jeśli tak, wydanie zostaje zatrzymane, a zespół dostaje informację, co poprawić.
Do analizy kodu źródłowego jeszcze przed zbudowaniem aplikacji służy mobsfscan, lżejsze narzędzie tego samego zespołu. Sprawdza kod w repozytorium i można je uruchamiać przy każdej zmianie zgłaszanej przez programistę. To podejście DevSecOps, w którym bezpieczeństwo jest częścią codziennej pracy zespołu, a nie jednorazowym audytem przed premierą.
Przy wdrażaniu automatu najważniejsze jest ustawienie progów. Zatrzymanie wydania przy każdym ostrzeżeniu sprawi, że zespół zacznie automat obchodzić. Lepiej zacząć od blokowania tylko problemów krytycznych, a pozostałe zbierać w raporcie do regularnego przeglądu. Taki automat warto połączyć z resztą testowania oprogramowania, żeby wyniki trafiały do tego samego miejsca co błędy funkcjonalne.
MobSF działa na podstawie wzorców. Widzi coś, co wygląda jak klucz, i zgłasza to jako klucz. Widzi użycie starego algorytmu szyfrowania w bibliotece, która korzysta z niego do czegoś niegroźnego, i też to zgłasza. Przy pierwszym raporcie fałszywych alarmów jest sporo, a ich przejrzenie zajmuje zwykle od kilku godzin do dnia pracy. Ważniejsze jest to, czego MobSF w ogóle nie widzi. Nie sprawdza serwera, z którym aplikacja się łączy. Jeśli API pozwala pobrać dane innego użytkownika po zmianie identyfikatora w zapytaniu, aplikacja może być w raporcie bez zarzutu, a dane i tak wyciekną. Większość poważnych incydentów dotyczy właśnie strony serwerowej, na przykład błędnej autoryzacji czy źle zabezpieczonych tokenów JWT. MobSF nie rozumie też logiki biznesowej. Nie wie, że kupon rabatowy nie powinien działać dwa razy ani że użytkownik bez opłaconego planu nie powinien widzieć treści premium. Takie problemy znajduje człowiek, który rozumie, jak aplikacja ma działać.
Dlatego MobSF to pierwsza linia kontroli, a nie zastępstwo testów penetracyjnych prowadzonych przez specjalistów. Automat pilnuje, żeby proste błędy nie wracały. Pentester szuka tego, czego automat nie zauważy.
Niezależnie od narzędzi obowiązują też podstawowe zasady bezpieczeństwa aplikacji mobilnych, takie jak szyfrowanie danych zapisanych w telefonie i ochrona API przed nieuprawnionym dostępem.
FAQ
Blog
W dzisiejszym cyfrowym świecie zapewnienie bezpieczeństwa aplikacji jest niezbędne. Podnoszenie poziomu ochrony przez Static Application Security Testing (SAST) to strategia, która pozwala na identyfikowanie potencjalnych luk bezpieczeństwa w kodzie źródłowym aplikacji. W artykule omówimy właśnie ten proces.
Zabezpieczenie aplikacji to poważne wyzwanie. DAST, czyli Dynamic Application Security Testing, to jedno z kluczowych narzędzi w walce o bezpieczeństwo naszych danych. Artykuł ten wprowadzi Cię w podstawy DAST, pokaże, jak przeprowadzić dynamiczne testowanie bezpieczeństwa i na co zwrócić uwagę podczas tego procesu.
CI/CD to skrót od Continuous Integration i Continuous Delivery, czyli procesów ciągłej integracji i ciągłego dostarczania. Jest to metoda zarządzania projektem oprogramowania, która polega na ciągłym i automatycznym sprawdzaniu, testowaniu i wdrażaniu kodu do produkcji.
DevSecOps, czyli zintegrowanie zasad zabezpieczeń z DevOps, zyskuje na znaczeniu w erze cyfrowej. Niniejszy artykuł poświęcony jest roli DevSecOps jako kluczowego kierunku w zarządzaniu bezpieczeństwem aplikacji. Tworzenie, testowanie i wdrażanie aplikacji nigdy nie było tak wymagające, a rola bezpieczeństwa nigdy nie była tak krytyczna.
Testy penetracyjne stanowią jedno z podstawowych narzędzi w środowisku IT, służące do ochrony organizacji przed cyfrowymi zagrożeniami. Poprzez symulację ataków hakerskich pozwalają na zidentyfikowanie i wzmocnienie potencjalnych słabości systemów. Są kluczowym elementem polityki bezpieczeństwa każdej firmy informatycznej.
Czy twoja aplikacja mobilna jest wystarczająco zabezpieczona? W erze cyfrowej, gdzie cyberprzestępczość jest coraz bardziej zaawansowana, bezpieczeństwo aplikacji mobilnych staje się priorytetem. Podzielę się praktycznymi poradami, które pomogą Ci chronić Twoje aplikacje przed potencjalnymi zagrożeniami.
