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

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

OWASP MASVS (Mobile Application Security Verification Standard) — открытый стандарт, который описывает, что должно уметь безопасное мобильное приложение. Требования сгруппированы по областям: STORAGE, CRYPTO, AUTH, NETWORK, PLATFORM, CODE, RESILIENCE и PRIVACY. Сопутствующее руководство MASTG объясняет, как проверить каждый пункт.

Главный принцип: приложение работает на устройстве, которое вы не контролируете. Всё, что лежит в бинарнике, можно прочитать, изменить и воспроизвести. Чек-лист ниже превращает стандарт в конкретные задачи.

STORAGE: где хранятся данные

• Токены, ключи и пароли храните только в iOS Keychain или хранилище на основе Android Keystore. Во Flutter используйте плагин вроде flutter_secure_storage, который оборачивает оба механизма.
• Никогда не кладите токены в UserDefaults, SharedPreferences, обычные файлы или SQLite без шифрования.
• Не логируйте персональные данные и токены, даже в debug-сборках, которые могут попасть к тестировщикам.
• Исключите чувствительные файлы из облачных бэкапов и скрывайте важные экраны в превью переключателя приложений.
• Очищайте буфер обмена после одноразовых кодов и отключайте автозамену для секретных полей.

NETWORK: защита трафика

• Только HTTPS. Не отключайте App Transport Security на iOS и задайте cleartextTrafficPermitted="false" на Android.
• Используйте certificate или public key pinning для своего API, чтобы поддельный сертификат на устройстве не позволял перехватить трафик.
  • Android: Network Security Config с <pin-set>.
  • iOS: NSPinnedDomains в Info.plist или сетевая библиотека с поддержкой pinning.
  • Flutter: собственный SecurityContext или HTTP-клиент с поддержкой pinning.
• Закрепляйте минимум два ключа (текущий и резервный) и планируйте ротацию, иначе истёкший сертификат заблокирует пользователей до обновления.

<domain-config>
  <domain includeSubdomains="true">api.example.com</domain>
  <pin-set expiration="2027-01-01">
    <pin digest="SHA-256">base64-primary-key-hash=</pin>
    <pin digest="SHA-256">base64-backup-key-hash=</pin>
  </pin-set>
</domain-config>

AUTH: сессии и вход

• Используйте короткоживущие access-токены и refresh-токены, которые сервер может отозвать.
• Биометрия должна разблокировать ключ в защищённом железе, а не просто возвращать приложению «true».
• Выход и отзыв токенов реализуйте на стороне сервера.

RESILIENCE: root, jailbreak и модификации

• Распознавайте root и jailbreak, фреймворки для хуков и отладчики. Реакцию выбирайте по риску: предупреждение в контентном приложении, блокировка платежей в финтехе.
• Предпочитайте платформенную аттестацию: Play Integrity API на Android и App Attest на iOS. Результат проверяет сервер, а не приложение.
• Помните, что локальные проверки обходятся; они повышают стоимость атаки, но не делают её невозможной.

CODE: гигиена сборки

• Включайте обфускацию и минификацию: R8/ProGuard на Android, flutter build --obfuscate --split-debug-info во Flutter. Файлы маппинга храните закрыто — они нужны для расшифровки крашей.
• Убирайте из релиза debug-меню, тестовые эндпоинты и подробные логи.
• Обновляйте зависимости и проверяйте их на известные уязвимости.

PLATFORM: deep links и взаимодействие с системой

• Используйте проверенные ссылки: Android App Links с assetlinks.json и iOS Universal Links с apple-app-site-association. Кастомную схему вроде myapp:// может перехватить другое приложение.
• Проверяйте каждый параметр deep link как недоверенный ввод. Ссылка не должна без подтверждения запускать платёж, менять настройки или открывать произвольный URL в WebView.
• Не экспортируйте Android-компоненты (activities, receivers, providers), которым не нужно быть публичными.
• В WebView отключайте JavaScript-мосты, где они не нужны, и загружайте только свои домены.

Что обязательно остаётся на сервере

Приложение — удобный интерфейс, источник истины — сервер.