Безопасность мобильного приложения: на что обратить внимание

Краткая оценка рисков и нормативных требований

Перед разработкой нужно оценить, какие данные обрабатывает приложение и какие требования к ним применимы: ФЗ‑152 «О персональных данных», требования банков (PCI DSS) для платежей, отраслевые стандарты безопасности. От этого зависит набор технических мер и требования к хранению, логированию и шифрованию.

Определите критичность данных (персональные, платежные, служебные ключи) и вероятность инцидента. Для малого и среднего бизнеса стандартный минимальный набор — шифрование на устройстве и в транспортном канале, аутентификация и контроль сессий, мониторинг и план реакции на инциденты.

Аутентификация и управление сессиями

Используйте проверенные протоколы: OAuth2/OpenID Connect для авторизации, JWT с коротким временем жизни и защищёнными refresh-токенами на сервере. Отказывайтесь от авторизации, основанной на статических токенах, встроенных в приложение.

• Минимум: TLS 1.2/1.3 и строжайшая проверка сертификата
• OAuth2 с PKCE для мобильных клиентов
• Короткий срок жизни access-токенов, refresh-токены — на сервере
• Блокировка сессий при подозрительной активности и обязательная повторная аутентификация для чувствительных операций

Шифрование данных: на устройстве и в канале

Все конфиденциальные данные должны храниться в зашифрованном виде: для Android — EncryptedSharedPreferences/Keystore; для iOS — Keychain + Data Protection. Нельзя хранить секреты или приватные ключи в коде или в общедоступных файлах.

Шифрование в канале — обязательное требование: HTTPS с современными наборами шифров, HSTS и certificate pinning для критичных приложений. Контроль версий TLS и регулярные обновления серверных сертификатов исключают MITM‑атаки.

Безопасность API и серверной логики

Основная уязвимость большинства мобильных приложений — уязвимые или недостаточно защищённые API. Каждая проверка прав доступа должна выполняться на сервере, а не полагаться на данные клиента. Внедрять rate limiting, проверку схемы входных данных и защиту от повторного воспроизведения запросов.

• Серверная валидация и авторизация — всегда
• Логирование и мониторинг аномалий с хранением доказательств для расследования
• Ограничение прав доступа по ролям и минимизация возвращаемых данных
• Версионирование API и контролируемые миграции

Защита на уровне устройства: root/jailbreak, хранение и сторонние SDK

Проверка среды выполнения: детектирование root/jailbreak, проверка целостности подписи приложения, контроль среды через SafetyNet/DeviceCheck или аналогичные сервисы. На скомпрометированном устройстве любой уровень защиты можно обойти, поэтому ограничивать доступ и информировать пользователя.

Аудит сторонних SDK: многие утечки и уязвимости приходят через сторонние библиотеки. Внедрить политику разрешённых SDK, обновления библиотек по готовым SR по уязвимостям и автоматическое сканирование зависимостей в CI.

Процесс разработки, тестирование и контроль качества

Безопасность нужно встроить в SDLC: статический анализ (SAST), динамический анализ (DAST) для серверов, интерактивный анализ (IAST) и регулярные пентесты. Включать security-gates в CI/CD: сборка не проходит, если найдены критичные уязвимости.

Реализовать процесс управления уязвимостями: SLAs на фиксацию критичных багов (например, 48–72 часа), трекинг через систему багов и регулярные ретроспективы. Для ключевых приложений — запуск программы bug bounty или независимого аудита перед релизом.

Чек-лист для проверки безопасности перед релизом

• Все сетевые вызовы через TLS 1.2/1.3 и проверка сертификатов
• Нет секретов в исходниках и конфигурациях; секреты в vault/Keystore
• Аутентификация через OAuth2/PKCE, короткие access-токены
• SAST/DAST прогоны, пентест и фиксация критичных уязвимостей
• Проверка сторонних SDK и использование подписанных сборок