Тестування безпеки мобільних застосунків у 2026 році: OWASP MASVS, чек-лист і інструменти

Сайт живе на сервері, до якого зловмисник не має доступу. Мобільний застосунок — навпаки: його файл APK чи IPA лежить у кожного, хто його завантажив. Будь-хто може розпакувати збірку, прочитати код, знайти прописані ключі API, змінити перевірки й запустити підроблену копію на телефоні з root. Тому безпека мобільного застосунку тримається на двох речах: що він зберігає й передає на самому пристрої і чи не довіряє сервер усьому, що приходить від клієнта.

У статті розповідаємо, що саме перевіряти в мобільних застосунках, як налаштувати робоче місце, які інструменти обрати для Android та iOS і де легально потренуватися. Загальні принципи безпеки вебзастосунків і API — у статті «Тестування безпеки», а функціональне мобільне тестування — у статті «Тестування мобільних застосунків».

Короткий вибір

Чим мобільна безпека відрізняється від вебу

• Клієнт у руках зловмисника. Усе, що вшито в застосунок, — ключі, адреси внутрішніх серверів, логіка перевірок, «приховані» функції — можна знайти декомпілятором. Секрет у коді клієнта перестає бути секретом.
• Дані на пристрої. Застосунок зберігає токени, кеш, бази SQLite, файли, скриншоти в перемикачі задач. Телефон можна загубити, на ньому може бути шкідливе ПЗ чи root.
• Взаємодія з іншими застосунками. Deep links, інтенти Android, content providers, URL-схеми й буфер обміну — канали, через які інший застосунок може передати шкідливі дані або забрати чужі.
• Мережа поза контролем. Публічний Wi-Fi, підроблені точки доступу, проксі. Застосунок має правильно перевіряти сертифікати сервера.
• Модифікація й підробка. Зловмисник може змінити застосунок (вимкнути перевірку покупки, рекламу чи root-детект), перепідписати й поширювати копію.
• Платформи різні. Android та iOS мають різні сховища (Keystore і Keychain), моделі дозволів і механізми захисту — перевіряти доводиться окремо.

OWASP Mobile Top 10 і MASVS

OWASP Mobile Top 10 — список найпоширеніших ризиків мобільних застосунків. Чинна версія — 2024 року:

1. Неправильне використання облікових даних — ключі й паролі в коді, передача облікових даних без захисту.

2. Недостатня безпека ланцюжка постачання — вразливі чи шкідливі SDK і бібліотеки, скомпрометоване збирання.

3. Небезпечна автентифікація й авторизація — перевірка прав лише на клієнті, слабкі сесії, обхід входу.

4. Недостатня перевірка вхідних і вихідних даних — ін’єкції, XSS у WebView, небезпечні deep links.

5. Небезпечна передача даних — HTTP замість HTTPS, вимкнена перевірка сертифікатів.

6. Недостатній захист приватності — зайві персональні дані, витоки в логи, аналітику й рекламні SDK.

7. Недостатній захист бінарного файлу — легко декомпілювати, змінити й перепакувати.

8. Неправильна конфігурація — налагодження в релізі, дозвіл на резервні копії, експортовані компоненти, зайві дозволи.

9. Небезпечне зберігання даних — токени й персональні дані відкритим текстом у файлах, базах, налаштуваннях.

10. Недостатня криптографія — застарілі алгоритми, власні «шифри», ключі поряд із зашифрованими даними.

Top 10 підказує, що шукати. Для системної перевірки є проєкт OWASP MAS:

• MASVS — стандарт вимог, згрупований у вісім розділів: STORAGE (зберігання), CRYPTO (криптографія), AUTH (автентифікація), NETWORK (мережа), PLATFORM (взаємодія з платформою), CODE (якість коду й залежності), RESILIENCE (стійкість до зламу й підробки) і PRIVACY (приватність);
• MASTG — посібник, як перевірити кожну вимогу на Android та iOS: техніки, тести, демо й рекомендації;
• MASWE — перелік типових слабких місць із посиланнями на тести;
• чек-лист — зручно взяти за основу тест-плану й звіту.

Не кожному застосунку потрібна максимальна стійкість: для гри достатньо базових вимог, а банку, медицині чи застосунку з платежами — ще й захист від зламу й підробки. Визначте рівень разом із командою на початку.

Робоче місце тестувальника

Пристрої. Для Android найзручніше мати окремий тестовий телефон, на який встановлено Magisk для root-доступу, або емулятор Android Studio чи Genymotion. Ніколи не робіть root на особистому телефоні з банківськими застосунками. Для iOS потрібен Mac із Xcode; глибокі перевірки потребують пристрою з jailbreak, який складно отримати для нових версій iOS, тому компанії використовують віртуальні пристрої Corellium.

Збірки. Просіть у розробників дві версії: релізну (саме вона потрапить до користувачів, на ній перевіряють захист) і налагоджувальну з довірою до вашого сертифіката проксі (на ній зручніше тестувати API).

Інструменти на комп’ютері: adb з Android SDK, перехоплювальний проксі (Burp Suite або mitmproxy), jadx, Apktool, Frida з objection і MobSF. MobSF найпростіше запустити в Docker:

docker run -it --rm -p 8000:8000 opensecurity/mobile-security-framework-mobsf:latest

Після запуску відкрийте http://localhost:8000 і перетягніть у вікно APK, AAB чи IPA.

Крок 1. Статичний аналіз: що всередині збірки

Статичний аналіз не потребує запуску застосунку — ви досліджуєте сам файл.

Автоматично. MobSF за кілька хвилин покаже дозволи, експортовані компоненти, небезпечні налаштування маніфесту, слабку криптографію, адреси серверів і можливі секрети. Хмарні сканери Ostorlab (є безкоштовний план), Oversecured, Appknox і NowSecure роблять те саме глибше й з інтеграцією в CI. Сприймайте звіт як список гіпотез: частина знахідок — хибні спрацювання.

Вручну. Розпакуйте й декомпілюйте застосунок:

apktool d app-release.apk -o app_src
jadx -d app_java app-release.apk

Відкрийте AndroidManifest.xml і перевірте:

• android:debuggable="true" — у релізній збірці бути не повинно;
• android:allowBackup="true" — дані застосунку можна витягти через резервну копію;
• android:exported="true" в activities, services, receivers і providers — кожен такий компонент доступний іншим застосункам і має перевіряти, хто й що йому надсилає;
• android:usesCleartextTraffic="true" і файл network_security_config.xml — чи дозволено HTTP і чи довіряє застосунок сертифікатам користувача;
• дозволи — чи справді потрібні застосунку контакти, SMS чи точна геолокація.

У коді jadx-gui шукайте api_key, secret, password, Bearer, http://, адреси тестових серверів і закоментовані функції. APKLeaks робить такий пошук автоматично. Нативні бібліотеки .so досліджують у Ghidra.

Для iOS IPA — це zip-архів: перевірте Info.plist (винятки App Transport Security NSAllowsArbitraryLoads, URL-схеми, дозволи) і рядки в бінарному файлі.

Ключі в коді — завжди дефект. Якщо в застосунку знайдено ключ платного API чи хмарного сховища, вважайте, що його вже знайшли інші. Правильне рішення — щоб ключ взагалі не потрапляв у клієнт, а запити йшли через власний сервер.

Крок 2. Сховище даних на пристрої

Встановіть застосунок, увійдіть, попрацюйте з ним, а потім подивіться, що лишилося на пристрої. На Android приватна папка застосунку — /data/data/<пакет>/; на тестовому пристрої з root або з налагоджувальною збіркою її можна переглянути через adb:

adb shell run-as com.example.app ls -R /data/data/com.example.app

Що перевіряти:

• SharedPreferences, бази SQLite, файли — немає паролів, токенів, номерів карток і персональних даних відкритим текстом;
• секрети зберігаються в Android Keystore чи iOS Keychain, а не в звичайних файлах;
• логи (adb logcat або Console на Mac) — у релізній збірці немає токенів, запитів і персональних даних;
• буфер обміну — поля паролів і кодів не дають копіювати, застосунок не читає буфер без потреби;
• скриншот у перемикачі задач — екрани з картками, кодами й балансом приховуються (на Android — FLAG_SECURE);
• кеш клавіатури — поля паролів і кодів не потрапляють у підказки клавіатури;
• зовнішнє сховище й завантаження — експортовані документи не лежать у публічних папках;
• після виходу з акаунта локальні дані й токени видаляються.

Крок 3. Мережа й API

Налаштуйте пристрій працювати через проксі на комп’ютері й встановіть сертифікат проксі. Нюанс Android: починаючи з Android 7 застосунки за замовчуванням не довіряють сертифікатам, встановленим користувачем. Тому для налагоджувальної збірки розробники додають у network_security_config.xml блок, який діє лише в debug-збірці:

<network-security-config>
  <debug-overrides>
    <trust-anchors>
      <certificates src="user" />
    </trust-anchors>
  </debug-overrides>
</network-security-config>

На iOS після встановлення профілю сертифіката його треба окремо ввімкнути в «Параметри → Загальні → Про пристрій → Параметри довіри сертифікатам».

Що перевіряти:

• весь трафік іде через HTTPS, жодних запитів відкритим текстом, зокрема від сторонніх SDK;
• релізна збірка не приймає підроблений сертифікат: без встановленого сертифіката проксі застосунок має відмовлятися з’єднуватися, а не мовчки працювати;
• SSL pinning, якщо заявлений, справді працює в релізі — і є план оновлення сертифікатів, щоб застосунок не «зламався» після їх заміни;
• API перевіряє права на сервері: підмініть id замовлення, роль, ціну, кількість бонусів — сервер має відмовити. Більшість серйозних вразливостей мобільних застосунків насправді сидить у бекенді;
• у відповідях немає зайвих даних, які застосунок просто не показує на екрані;
• токени мають строк дії й відкликаються після виходу чи зміни пароля.

Застосунки на Flutter ігнорують системний проксі, тому для них стане в пригоді reFlutter. HTTP Toolkit налаштовує перехоплення на Android-пристрої в кілька кліків, а Proxyman і Charles Proxy зручні на Mac. Детальніше про перевірку API — у статті «Тестування API».

Крок 4. Взаємодія з платформою: deep links, компоненти, WebView

Deep links і URL-схеми. Застосунок відкривається з посилання — отже, будь-хто може надіслати користувачу посилання з довільними параметрами. На Android посилання зручно викликати з adb:

adb shell am start -W -a android.intent.action.VIEW -d "myapp://reset-password?token=test" com.example.app

Перевірте, що посилання не виконують дій без підтвердження (переказ, зміна email), не відкривають довільні адреси у WebView і не обходять екран входу. Для HTTPS-посилань перевірте App Links (Android) і Universal Links (iOS) — щоб інший застосунок не міг перехопити посилання вашого домену.

Експортовані компоненти Android. drozer знаходить activities, services, receivers і content providers, доступні іншим застосункам, і перевіряє їх на витік даних, SQL-ін’єкції та обхід дозволів.

WebView. Якщо застосунок показує вебсторінки всередині, перевірте: чи ввімкнено JavaScript лише там, де треба, чи не відкриваються довільні адреси, чи немає небезпечних мостів між JavaScript і нативним кодом, чи не доступні локальні файли.

Дозволи. Відхиліть кожен дозвіл і переконайтеся, що застосунок не падає й не обходить відмову. Перевірте, що дані з камери, геолокації й контактів не надсилаються туди, куди не повинні.

Крок 5. Аналіз під час роботи: Frida та objection

Frida підключається до запущеного застосунку й дозволяє стежити за викликами функцій і змінювати їх: подивитися, що застосунок шифрує й куди надсилає, підмінити результат перевірки root чи покупки, обійти SSL pinning. objection — надбудова над Frida з готовими командами, наприклад android sslpinning disable чи ios keychain dump у своїй консолі, без написання скриптів.

Що перевіряти на цьому кроці:

• чи працюють важливі перевірки на сервері, а не лише в застосунку: якщо Frida «вимикає» перевірку покупки й платна функція відкривається — сервер довіряє клієнту;
• чи зберігаються в пам’яті паролі й ключі довше, ніж потрібно;
• біометрія: чи прив’язаний вхід через Face ID чи відбиток до ключа в Keystore/Keychain, чи це просто перемикач «так/ні», який легко підмінити.

Крок 6. Стійкість до зламу й підробки

Ці перевірки потрібні застосункам, де підробка має реальну ціну: банки, платежі, ігри з внутрішніми покупками, медицина.

• Root і jailbreak. Як застосунок поводиться на пристрої з root: попереджає, обмежує функції чи завершує роботу — згідно з вимогами продукту.
• Емулятор, налагоджувач і Frida. Чи помічає застосунок, що його запущено в емуляторі чи під інструментом перехоплення.
• Модифікація. Розберіть застосунок Apktool, змініть щось незначне, зберіть і перепідпишіть — чи помітить застосунок або сервер, що це не оригінал?
• Обфускація. Чи важко читати декомпільований код (R8/ProGuard на Android, обфускатори для iOS).

Тут важливо розуміти: будь-який захист на клієнті можна обійти, він лише підвищує вартість атаки. Тому найкраще працює поєднання захисту в застосунку — наприклад, безкоштовний SDK freeRASP — і перевірки на сервері, що запит прийшов від справжнього застосунку: Play Integrity API від Google, App Attest від Apple або сервіс Approov.

Крок 7. Ланцюжок постачання й приватність

• Сторонні SDK і бібліотеки. Реклама, аналітика, чати, платежі — кожен SDK отримує ті самі права, що й ваш застосунок. MobSF і комерційні сканери складають перелік компонентів (SBOM); залежності в репозиторії перевіряють Snyk чи Trivy, а код — Semgrep, у якого є правила для Kotlin, Java і Swift.
• Відповідність заявам у магазинах. Дані, які застосунок фактично збирає й надсилає (видно в проксі), мають збігатися з розділом «Безпека даних» у Google Play і маніфестом приватності в App Store.
• Персональні дані. Чи можна видалити акаунт і дані з застосунку, чи не потрапляють персональні дані в аналітику й звіти про збої.

Чек-лист для швидкої перевірки

Збірка й конфігурація

• реліз без debuggable, без зайвих дозволів і експортованих компонентів;
• allowBackup вимкнено або налаштовано правила виключень;
• у коді й ресурсах немає ключів, паролів, адрес тестових серверів.

Дані

• токени й секрети — лише в Keystore/Keychain;
• у файлах, базах, логах і кеші немає персональних даних відкритим текстом;
• чутливі екрани приховано в перемикачі задач, після виходу дані видаляються.

Мережа й API

• лише HTTPS; підроблений сертифікат у релізі не приймається;
• права перевіряються на сервері: чужі id, ролі, ціни відхиляються;
• токени мають строк дії й відкликаються.

Платформа

• deep links не виконують дій без підтвердження й не відкривають довільні адреси;
• WebView обмежено, мости JavaScript безпечні;
• відмова в дозволах обробляється коректно.

Стійкість (якщо потрібна)

• реакція на root, jailbreak, емулятор, Frida і модифікацію відповідає вимогам;
• сервер перевіряє, що запит від справжнього застосунку.

Знайдені вразливості оформлюйте як баги з позначкою безпеки й обмеженим доступом у трекері, вказуючи версію збірки, пристрій і ОС, кроки, доказ і посилання на вимогу MASVS. Не публікуйте деталі до виправлення.

Безпека в CI

Автоматичні перевірки краще запускати на кожну збірку, а не раз перед релізом:

• статичний аналіз коду й залежностей — Semgrep, Snyk, Gitleaks для секретів у репозиторії;
• сканування готової збірки — MobSF через REST API або хмарні сервіси Ostorlab, Oversecured, Appknox з інтеграціями для GitHub Actions та інших CI;
• ручне тестування й пентест — для нових критичних функцій і перед великими релізами.

Для застосунків, яким важливе незалежне підтвердження, існує програма MASA (App Defense Alliance): акредитовані лабораторії перевіряють застосунок за MASVS, а Google Play може показувати позначку незалежної перевірки безпеки.

Де легально потренуватися

• OWASP MAS — MASTG з демо й завдання MAS Crackmes для практики реверс-інжинірингу на Android та iOS;
• AndroGoat — навмисно вразливий Android-застосунок на Kotlin із понад 30 завданнями: сховище, WebView, компоненти, pinning, root;
• DVIA-v2 — навмисно вразливий iOS-застосунок на Swift: сховище, jailbreak, біометрія, мережа, патчинг;
• OWASP crAPI — вразливий API, через який працюють мобільні клієнти, для практики OWASP API Top 10;
• MobSF — проганяйте через нього навчальні застосунки й порівнюйте автоматичні знахідки з власними.

Більше тренажерів — у статті «Тренажери для тестувальників».

План навчання на місяць

АІ в тестуванні безпеки мобільних застосунків

АІ-асистенти, як-от Claude Code, Cursor чи GitHub Copilot, допомагають розібратися в декомпільованому коді, пояснюють знахідки MobSF, пишуть скрипти Frida й пропонують виправлення. Комерційні платформи на кшталт Ostorlab, Oversecured і Appknox використовують АІ-агентів, які самі входять у застосунок і намагаються підтвердити знахідки. Але АІ помиляється: кожну знахідку перевіряйте вручну, а код і збірки клієнтів не передавайте в сторонні сервіси без дозволу.

Про інші види тестування читайте в статтях «Тестування безпеки», «Тестування мобільних застосунків» та «Тестування API». Усі інструменти з цієї статті є в підкатегоріях Тестування і Безпека коду та застосунків.

Часті запитання

Чи потрібен телефон з root або jailbreak?

Для початку — ні. Статичний аналіз, перевірка трафіку з налагоджувальною збіркою й API не потребують root. Для перевірки сховища, обходу pinning і стійкості до зламу зручніше мати окремий тестовий Android-телефон з root або емулятор. Для iOS компанії часто беруть віртуальні пристрої Corellium.

З чого почати мануальному тестувальнику?

Проженіть збірку через MobSF, налаштуйте перехоплення трафіку й перевірте права в API — підміна id та ролей знаходить найбільше реальних проблем. Далі вивчайте MASTG і тренуйтеся на AndroGoat.

Чи захищає SSL pinning від усього?

Ні. Pinning захищає від перехоплення трафіку в мережі, але на пристрої з root його обходять за хвилини. Безпека має триматися на сервері: перевірці прав, строках дії токенів і, за потреби, атестації застосунку.

Чи достатньо обфускації, щоб сховати ключ API?

Ні. Обфускація лише ускладнює читання коду. Будь-який ключ, що потрапив у застосунок, можна знайти. Чутливі запити мають іти через ваш сервер.

Android чи iOS безпечніший?

У кожної платформи свої механізми й типові помилки, і вразливості частіше залежать від самого застосунку й бекенду, ніж від ОС. Тестувати потрібно обидві версії окремо.

Не знаєте, з чого почати?

Запитайте Елю: вона підбере інструменти для тестування безпеки вашого мобільного застосунку.

Дата перевірки фактів: 5 листопада 2026 року. Умови сервісів можуть змінюватися, тож перевіряйте їх на офіційних сайтах.