Чек-лист безопасности мобильного приложения по OWASP MASVS

Что такое MASVS и как им пользоваться

OWASP MASVS (Mobile Application Security Verification Standard) — открытый стандарт требований к безопасности мобильных приложений. К нему прилагается MASTG — руководство с методиками тестирования. Стандарт не говорит, как писать код, а задаёт, что должно быть проверено.

Категории MASVS:

Не все требования нужны каждому приложению. Банку и медицинскому сервису нужна устойчивость к реверсу, каталогу товаров — обычно нет. Сначала определите модель угроз, потом выбирайте глубину проверок.

Хранение данных (STORAGE, CRYPTO)

• Токены и ключи — только в Keychain (iOS) и Android Keystore / EncryptedSharedPreferences, а не в UserDefaults, SharedPreferences или файлах.
• В логах нет токенов, паролей, номеров карт и персональных данных — в том числе в релизной сборке.
• Кэш, скриншоты в переключателе приложений и буфер обмена не раскрывают чувствительные экраны.
• Резервные копии не уносят секреты: проверьте настройки бэкапа на Android и атрибуты защиты файлов на iOS.
• Нет собственной криптографии и захардкоженных ключей; используются стандартные API платформы.

Сеть и certificate pinning (NETWORK)

• Весь трафик идёт по TLS; ATS на iOS и Network Security Config на Android не содержат исключений «разрешить всё».
• Приложение не принимает самоподписанные или невалидные сертификаты — проверьте, что отладочный код не попал в релиз.
• Certificate pinning — для приложений с высоким риском. Пиньте публичный ключ, держите резервный пин и продумайте ротацию: ошибка в pinning может отрезать всех пользователей от сервера до выхода обновления.

<network-security-config>
  <base-config cleartextTrafficPermitted="false" />
</network-security-config>

Авторизация (AUTH)

• Решение о доступе принимает сервер, а не приложение. Скрытая кнопка — не защита.
• Access-токены короткоживущие, refresh-токены можно отозвать, выход из аккаунта инвалидирует сессию на сервере.
• Биометрия привязана к ключу в защищённом хранилище, а не к булевому флагу «пользователь прошёл Face ID».
• Чувствительные операции (смена телефона, вывод средств) требуют повторного подтверждения.

Платформа и код (PLATFORM, CODE)

• Deep links и intent-ы проверяют входные данные и не открывают внутренние экраны без авторизации.
• Экспортируемые компоненты Android минимальны; WebView не открывает произвольные URL и не выставляет лишние JS-мосты.
• Запрашиваются только нужные разрешения.
• Зависимости обновляются, известные уязвимости отслеживаются; есть механизм принудительного обновления.

Реверс и модификация (RESILIENCE)

Любое клиентское приложение можно разобрать. Цель — не сделать это невозможным, а поднять стоимость атаки для действительно ценных данных:

• обфускация (R8, обфускация Dart, нативные инструменты);
• обнаружение root/jailbreak, отладчика и хуков — как сигнал, а не как единственная защита;
• проверка целостности через Play Integrity API и App Attest на стороне сервера;
• секреты, которые нельзя раскрывать, не хранятся в приложении вообще.

Базовое ревью перед релизом

1. Определите модель угроз и уровень требований.
2. Пройдите чек-лист по категориям выше вместе с разработчиками.
3. Запустите статический анализ (например, MobSF) по релизной сборке.
4. Проверьте трафик через прокси на тестовом устройстве.
5. Посмотрите содержимое песочницы приложения после типичного сценария.
6. Зафиксируйте найденное, приоритизируйте и закройте критичное до релиза.