Bezpieczeństwo aplikacji mobilnej opiera się na 8 obszarach standardu OWASP MASVS - od przechowywania danych po odporność na modyfikacje - oraz na przetwarzaniu danych osobowych zgodnie z RODO. Podstawowe zabezpieczenia powinny być w cenie każdej aplikacji na zamówienie, a dodatkowe, jak test penetracyjny, zależą od tego, jak wrażliwe dane przetwarzasz.
Poniżej rozpisujemy najczęstsze zagrożenia wraz z zabezpieczeniem i jego kosztem, pokazujemy, co RODO zmienia w projekcie, jak prosić o uprawnienia i jak sprawdzić aplikację przed publikacją. Tekst jest dla osób, które zamawiają aplikację, a nie dla pentesterów.
Co oznacza „bezpieczna aplikacja mobilna” w 2026 roku?
Najczęściej używaną miarą bezpieczeństwa aplikacji mobilnej jest OWASP MASVS (Mobile Application Security Verification Standard) - otwarty standard fundacji OWASP. Opisuje, co aplikacja musi spełniać, a towarzyszący mu przewodnik MASTG - jak to przetestować. Dzięki temu „bezpieczeństwo” przestaje być deklaracją i staje się listą do sprawdzenia.
MASVS dzieli wymagania na 8 grup:
- STORAGE - bezpieczne przechowywanie danych na telefonie,
- CRYPTO - poprawna kryptografia i zarządzanie kluczami,
- AUTH - logowanie i sprawdzanie uprawnień,
- NETWORK - szyfrowana komunikacja z serwerem,
- PLATFORM - bezpieczne korzystanie z funkcji systemu i innych aplikacji,
- CODE - jakość kodu, aktualne biblioteki, walidacja danych,
- RESILIENCE - odporność na analizę i modyfikację aplikacji,
- PRIVACY - ochrona prywatności i minimalizacja danych.
Pamiętaj jednak, że aplikacja to tylko jedna trzecia układu. Pozostałe dwie to serwer z API i telefon użytkownika. Najlepiej zabezpieczona aplikacja nie pomoże, jeśli API zwraca dane każdemu, kto zna adres - dlatego uprawnienia zawsze sprawdza serwer, nie telefon.
Jakie są najczęstsze zagrożenia dla bezpieczeństwa aplikacji mobilnej?
Tabela łączy najczęstsze kategorie ryzyka z listy OWASP Mobile Top 10 (edycja 2024) z typowym zabezpieczeniem i względnym poziomem jego kosztu. „W cenie” oznacza element, który powinien być w każdej profesjonalnie wykonanej aplikacji i nie wymaga osobnej pozycji w wycenie.
| Zagrożenie (OWASP Mobile Top 10) | Jak wygląda w praktyce | Zabezpieczenie | Koszt |
|---|---|---|---|
| Niezabezpieczone przechowywanie danych (M9) | Token logowania lub dane klienta zapisane otwartym tekstem w pamięci telefonu | Keychain i Keystore, szyfrowanie lokalnej bazy, brak danych w logach | W cenie; szyfrowana baza offline - dodatek o niskim koszcie |
| Niewłaściwe użycie danych logowania (M1) | Klucz do płatności albo hasło do serwera wpisane w kod aplikacji | Sekrety wyłącznie po stronie serwera, rotacja kluczy | W cenie |
| Słabe uwierzytelnianie i autoryzacja (M3) | Użytkownik po zmianie numeru w adresie widzi cudze zamówienie | Uprawnienia sprawdzane na serwerze, tokeny z krótkim czasem życia, biometria | W cenie; logowanie dwuskładnikowe - dodatek o średnim koszcie |
| Niezabezpieczona komunikacja (M5) | Dane przechwycone w publicznej sieci Wi-Fi | Wyłącznie HTTPS (TLS 1.2+), przypinanie certyfikatu przy danych wrażliwych | W cenie; przypinanie certyfikatu - najtańszy dodatek w zestawieniu |
| Niebezpieczny łańcuch dostaw (M2) | Podatna biblioteka zewnętrzna albo SDK reklamowe zbierające dane | Skanowanie zależności, lista komponentów (SBOM), regularne aktualizacje | W utrzymaniu, zwykle kilka godzin miesięcznie |
| Brak walidacji danych (M4) | Złośliwy tekst w formularzu wykonuje zapytanie do bazy | Walidacja po stronie serwera, parametryzowane zapytania | W cenie |
| Niewystarczająca ochrona prywatności (M6) | Aplikacja pobiera kontakty i dokładną lokalizację „na wszelki wypadek” | Minimalne uprawnienia, zgody, anonimizacja danych analitycznych | W cenie |
| Brak ochrony kodu aplikacji (M7) | Zmodyfikowana wersja aplikacji omija płatność albo limit | Obfuskacja, wykrywanie roota i jailbreaka, Play Integrity i App Attest | Najdroższy dodatek w zestawieniu |
Które zabezpieczenia są w cenie, a które są dodatkiem?
Poziomy kosztu dodatków są orientacyjne i dotyczą aplikacji o średniej złożoności. Koszt rośnie, gdy zabezpieczenie trzeba wdrożyć w istniejącej aplikacji zamiast zaplanować je od początku.
Z tabeli wynika ważna rzecz: bezpieczeństwo aplikacji mobilnej w większości nie jest dodatkiem, tylko sposobem pisania kodu. Jeśli wykonawca wycenia osobno „szyfrowanie połączenia” albo „sprawdzanie uprawnień na serwerze”, zapytaj, co dostałbyś bez tej pozycji.
Jak RODO wpływa na projekt aplikacji mobilnej?
RODO nie mówi, jak pisać kod, ale wymusza kilka decyzji projektowych. Artykuł 25 wymaga ochrony danych w fazie projektowania, a artykuł 5 - minimalizacji: zbierasz tylko to, czego aplikacja naprawdę potrzebuje do działania.
Umowa powierzenia i odpowiedzialność
Administratorem danych użytkowników jest Twoja firma, a software house utrzymujący serwery jest podmiotem przetwarzającym. Potrzebna jest więc umowa powierzenia z artykułu 28. Na wypadek wycieku ustal z góry, kto i jak szybko Cię informuje - na zgłoszenie do UODO masz 72 godziny.
Dane szczególnie wrażliwe i lokalizacja
Dane o zdrowiu należą do szczególnych kategorii z artykułu 9 i zwykle wymagają oceny skutków dla ochrony danych (DPIA). Dotyczy to też stałego śledzenia lokalizacji, np. kierowców. Lokalizacja to dane osobowe, nawet gdy nie stoi przy niej imię i nazwisko.
Jeżeli budujesz aplikację medyczną lub farmaceutyczną, wymagań jest więcej - opisujemy je na stronie o aplikacjach dla farmacji i medycyny.
Usuwanie konta
Prawo do usunięcia danych z artykułu 17 ma swój odpowiednik w sklepach. Apple i Google wymagają, by aplikacja, w której można założyć konto, pozwalała też je usunąć. Google Play wymaga dodatkowo linku do usunięcia konta przez stronę internetową, dostępnego bez instalowania aplikacji.
Opisz aplikację w 3 zdaniach - odsyłamy przedział cenowy w 24 h w dni robocze. Napisz też, jakie dane będzie przetwarzać - wskażemy potrzebny poziom bezpieczeństwa aplikacji mobilnej i to, ile kosztuje ponad standard. wypełnij formularz, napisz na biuro@appcreo.pl albo zadzwoń: +48 783 477 243.
O jakie uprawnienia może prosić aplikacja mobilna i jak to zrobić?
Każde uprawnienie to kompromis między funkcją a zaufaniem. Użytkownik, który na starcie widzi pięć próśb o dostęp, często zamyka aplikację. Sklep, który widzi niepotrzebne uprawnienia, może zażądać wyjaśnień albo odrzucić aktualizację.
Oba systemy dają dziś użytkownikowi więcej kontroli: przybliżoną lokalizację zamiast dokładnej, dostęp do wybranych zdjęć zamiast całej galerii, zgodę „tylko raz”. Aplikacja musi działać sensownie także wtedy, gdy użytkownik wybierze wariant najbardziej ograniczony.
Jak projektować prośby o uprawnienia:
- Proś w momencie użycia funkcji, a nie przy pierwszym uruchomieniu - o aparat dopiero wtedy, gdy ktoś chce zrobić zdjęcie.
- Przed systemowym oknem pokaż jedno zdanie, po co aplikacji ten dostęp i co z niego ma użytkownik.
- Wybieraj najmniejszy zakres: przybliżona lokalizacja, systemowy wybór zdjęć zamiast dostępu do całej galerii.
- Lokalizację w tle stosuj tylko wtedy, gdy jest sercem produktu - oba sklepy wymagają jej uzasadnienia.
- Obsłuż odmowę: aplikacja ma działać dalej i podpowiadać, jak włączyć dostęp w ustawieniach.
- Opisz zbierane dane w etykietach prywatności App Store i sekcji „Bezpieczeństwo danych” w Google Play - zgodnie z tym, co robi kod i biblioteki zewnętrzne.
W aplikacjach dla firm dochodzą także role i uprawnienia wewnętrzne. Przykładem jest aplikacja do rejestracji czasu pracy dla CLAR System z rozbudowanym systemem uprawnień - pracownik, kierownik i administrator widzą w niej zupełnie inne dane.
Jak sprawdzić, czy aplikacja mobilna jest bezpieczna przed publikacją?
Bezpieczeństwo aplikacji mobilnej sprawdza się etapami, a nie jednym testem tuż przed premierą. Proces, który możesz wpisać do harmonogramu i umowy z wykonawcą:
- Na starcie określ, jakie dane przetwarza aplikacja i co by się stało po ich wycieku - to wyznacza poziom zabezpieczeń.
- Wybierz profil wymagań MASVS: podstawowy dla większości aplikacji, rozszerzony z grupą RESILIENCE dla finansów i zdrowia.
- Włącz automatyczne skanowanie kodu i bibliotek przy każdej zmianie w repozytorium.
- Wprowadź przegląd kodu przez drugą osobę dla logowania, płatności i uprawnień.
- Przed publikacją przetestuj aplikację według przewodnika MASTG, łącznie z API.
- Przy danych wrażliwych zamów dodatkowo test penetracyjny u niezależnej firmy.
- Przygotuj procedurę na incydent: kto zgłasza, w jakim czasie, kto wydaje poprawkę.
Ostatni punkt ma od 11 września 2026 roku podstawę prawną. Cyber Resilience Act obejmuje aplikacje mobilne i nakłada na producenta obowiązek zgłaszania aktywnie wykorzystywanych podatności - wstępnie w ciągu 24 godzin. Pełne obowiązki, w tym lista komponentów i okres wsparcia, wchodzą 11 grudnia 2027 roku.
Formalności sklepowe - deklaracje prywatności, weryfikację kont i najczęstsze powody odrzuceń - opisaliśmy w przewodniku o publikacji aplikacji w App Store i Google Play.
Od czego zależy koszt bezpieczeństwa i kiedy warto dopłacić?
Podstawowe zabezpieczenia są częścią ceny każdej aplikacji na zamówienie - aktualne ceny AppCreo znajdziesz w cenniku. Dopłata za bezpieczeństwo aplikacji mobilnej zależy od danych, które przetwarzasz, a nie od jej wielkości. Mała aplikacja do wyników badań potrzebuje więcej ochrony niż duży katalog produktów.
Trzy poziomy zabezpieczeń
- Podstawowy - katalogi, rezerwacje, narzędzia wewnętrzne bez danych wrażliwych: zabezpieczenia w cenie aplikacji.
- Rozszerzony - konta klientów, płatności, dane kontaktowe na dużą skalę: dodatkowo biometria, przypinanie certyfikatu, przegląd bezpieczeństwa. Dla skali: w badaniu IBM i Ponemon Institute (2015, ponad 400 dużych firm) na zabezpieczenie aplikacji mobilnych szło średnio tylko 5,5% budżetu ich budowy.
- Wysoki - zdrowie, finanse, dane dzieci: dodatkowo ochrona kodu, test penetracyjny, DPIA - dopłata wyraźnie wyższa niż przy poziomie rozszerzonym.
Koszt testu penetracyjnego aplikacji mobilnej razem z API zależy od liczby ekranów, ról i integracji. Warto go powtórzyć po dużej zmianie, np. dodaniu płatności.
Dla porównania: RODO przewiduje kary do 20 mln euro albo 4% rocznego obrotu, a sam wyciek oznacza koszty obsługi incydentu, powiadomień i utraty zaufania. Dlatego przy danych wrażliwych oszczędzanie na zabezpieczeniach rzadko się broni.
Zapisy o bezpieczeństwie, powierzeniu danych i terminach poprawek warto mieć w umowie - pomoże w tym nasz tekst o umowie z software housem. Jak prowadzimy projekty, pokazujemy na stronie tworzenia aplikacji mobilnych.
