Безопасность мобильного приложения — это комплекс мер на уровне кода, хранения данных, сетевого обмена и серверного API, который защищает пользователей и бизнес от утечек, взлома и финансовых потерь. Базовый ориентир — стандарт OWASP Mobile Top 10 и чек-лист MASVS, по которым проверяется каждый релиз.

Почему уязвимое приложение дороже защищённого

Мобильное приложение живёт во враждебной среде: его можно скачать, декомпилировать и изучить на устройстве злоумышленника — в отличие от серверного кода, который атакующий не видит. Поэтому ошибки, простительные веб-сайту, в мобильной разработке становятся критичными: захардкоженный API-ключ в APK находится за минуты утилитой jadx, а токен, сохранённый в открытом виде, читается на рутованном устройстве без усилий.

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

За 18 лет работы и 300+ проектов команда Applications.kz пришла к простому правилу: безопасность, заложенная на этапе архитектуры, стоит 5–10% бюджета разработки. Безопасность, «прикрученная» после инцидента, — кратно дороже, потому что включает рефакторинг, форс-мажорный релиз и работу с последствиями.

OWASP Mobile Top 10: карта рисков

OWASP Mobile Top 10 — отраслевой рейтинг самых распространённых уязвимостей мобильных приложений. Актуальная редакция выглядит так:

  • M1. Неправильное использование учётных данных — захардкоженные ключи, пароли и токены в коде приложения.
  • M2. Небезопасная цепочка поставок — уязвимые сторонние SDK и библиотеки, скомпрометированные зависимости.
  • M3. Небезопасная аутентификация и авторизация — слабые схемы входа, проверка прав только на клиенте.
  • M4. Недостаточная валидация ввода и вывода — инъекции, XSS в WebView, обработка непроверенных данных.
  • M5. Небезопасная коммуникация — трафик без TLS, отключённая проверка сертификатов, отсутствие pinning.
  • M6. Неадекватный privacy-контроль — избыточный сбор данных, утечки через логи и аналитику.
  • M7. Недостаточная защита бинарника — отсутствие обфускации, лёгкий реверс-инжиниринг и модификация APK/IPA.
  • M8. Ошибки конфигурации — debug-флаги в продакшене, открытые экспортированные компоненты Android, лишние разрешения.
  • M9. Небезопасное хранение данных — токены и персональные данные в SharedPreferences/UserDefaults открытым текстом.
  • M10. Недостаточная криптография — самописные алгоритмы, устаревшие MD5/SHA-1, ключи рядом с зашифрованными данными.

Важно понимать: это не экзотика. На аудитах сторонних проектов регулярно встречаются три-четыре пункта из этого списка одновременно — чаще всего M1, M5 и M9.

Типовые уязвимости, которые встречаются чаще всего

Секреты в коде клиента

Классика: ключ платёжного шлюза, токен Firebase или строка подключения к стороннему API лежат прямо в исходниках. После декомпиляции APK они доступны любому. Правильный подход — секреты живут только на сервере, клиент получает короткоживущие токены через защищённый бэкенд.

Токены в открытом хранилище

Access-токен в SharedPreferences без шифрования читается на устройстве с root-доступом или через бэкап. Решение — Android Keystore и iOS Keychain с аппаратным шифрованием, короткий срок жизни access-токена и ротация refresh-токена. Как грамотно построить вход через сторонние сервисы, мы показали в разборе OAuth-авторизации в приложении.

Доверие любому сертификату

Разработчик на этапе отладки отключает проверку TLS-сертификата «чтобы работало с локальным сервером» — и забывает вернуть обратно. Итог: атака man-in-the-middle в публичном Wi-Fi перехватывает логины и платежи. Лечится certificate pinning и обязательной проверкой сетевого слоя перед релизом.

Логика безопасности на клиенте

Проверка «является ли пользователь админом» выполняется в коде приложения, а API доверчиво выполняет любой запрос. Атакующему достаточно вызвать эндпоинт напрямую через Postman. Правило железное: клиент — это интерфейс, все проверки прав дублируются на сервере.

Уязвимые зависимости

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

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

Этот список мы используем как обязательный этап контроля качества в собственной разработке мобильных приложений. Он не заменяет полный аудит, но закрывает большинство типовых проблем.

Хранение данных

  • Токены и ключи — только в Keychain (iOS) / Keystore (Android), не в plain-хранилищах.
  • Локальная база (SQLite/Realm) с чувствительными данными зашифрована.
  • В логах продакшен-сборки нет персональных данных, токенов и тел запросов.
  • Снимок приложения в переключателе задач скрывает чувствительные экраны.

Сеть

  • Весь трафик — только HTTPS/TLS 1.2+, cleartext-трафик запрещён конфигурацией.
  • Certificate pinning включён для критичных эндпоинтов: платежи, авторизация.
  • В URL не передаются токены и персональные данные — они оседают в логах серверов и прокси.

Аутентификация и API

  • Access-токен короткоживущий, refresh-токен ротируется при каждом использовании.
  • Все проверки прав продублированы на сервере, на чувствительных эндпоинтах есть rate limiting.
  • Биометрия используется как удобный разблокировщик Keychain, а не как единственный фактор.
  • Сессия принудительно завершается на сервере при выходе и смене пароля.

Код и сборка

  • В бинарнике нет секретов: проверено поиском строк по декомпилированной сборке.
  • Обфускация (R8/ProGuard) включена, debug-флаги и тестовые эндпоинты вырезаны.
  • Зависимости проверены на известные CVE, версии зафиксированы.
  • WebView: JavaScript-мосты ограничены, загрузка произвольных URL запрещена.
  • Для финтех-приложений — детект root/jailbreak и реакция по политике риска.

Сколько стоит безопасность в Казахстане

Ориентиры по рынку Казахстана на 2026 год — для приложений малого и среднего масштаба. Точная цифра зависит от размера кодовой базы, количества ролей и интеграций.

Работа Что входит Стоимость, ₸
Экспресс-аудит по OWASP Статический анализ, проверка хранения, сети и сборки, отчёт с приоритетами от 450 000
Полный аудит приложения + API SAST + ручной анализ, тестирование бэкенда, ретест после исправлений 900 000 – 2 500 000
Пентест мобильного продукта Имитация атаки: реверс, MITM, обход защиты, эксплуатация API 1 500 000 – 4 000 000
Встроенная безопасность при разработке Архитектура, secure-кодинг, проверки в CI/CD +5–10% к бюджету проекта
Исправление найденных уязвимостей Рефакторинг проблемных модулей по итогам аудита от 300 000

Самая выгодная строка — «встроенная безопасность»: закладывать защиту при разработке дешевле, чем чинить готовый продукт. Именно поэтому в наших проектах разработки мобильных приложений в Алматы security-чек-лист — обязательный этап перед каждым релизом, а не отдельная услуга по запросу.

Как встроить безопасность в процесс, а не в авральный спринт

Рабочая схема, которую мы применяем на проектах для рынков Казахстана, ОАЭ и Таиланда:

  • На старте — моделирование угроз: какие данные обрабатываем, кто и зачем будет атаковать, какие сценарии критичны для бизнеса.
  • В архитектуре — секреты на сервере, минимально необходимые разрешения, шифрование по умолчанию, проверки прав в API.
  • В разработке — code review с фокусом на безопасность, линтеры и статический анализ в каждом pull request.
  • В CI/CD — автоматический скан зависимостей, проверка конфигурации сборки, запрет debug-артефактов в релизе.
  • Перед релизом — прогон по чек-листу выше; для платёжных и медицинских продуктов — внешний пентест.
  • После релиза — мониторинг инцидентов, план реагирования и регулярное обновление зависимостей.

Такой процесс не тормозит разработку: автоматические проверки занимают минуты, а ручной аудит планируется как обычная задача спринта. Тормозит как раз обратное — простой продукта и экстренные патчи после взлома.

Частые вопросы

Достаточно ли проверки Google Play и App Store для безопасности приложения?

Нет. Модерация сторов отсеивает вредоносный софт и грубые нарушения политик, но не проверяет ваш код на уязвимости. Захардкоженные ключи, незащищённое хранилище токенов и дырявый API спокойно проходят ревью. Ответственность за безопасность данных пользователей лежит на владельце приложения, и стандартом проверки остаётся OWASP MASVS, а не чек-лист магазина.

Что такое OWASP MASVS и чем он отличается от Mobile Top 10?

Mobile Top 10 — рейтинг самых частых уязвимостей, удобный для понимания рисков. MASVS (Mobile Application Security Verification Standard) — полноценный стандарт верификации: структурированный список требований по хранению, криптографии, аутентификации, сети и защите бинарника. На практике Top 10 используют для приоритизации, а MASVS — как чек-лист при аудите и приёмке проекта.

Сколько времени занимает аудит безопасности мобильного приложения?

Экспресс-аудит среднего приложения — 5–10 рабочих дней: статический анализ, проверка хранения и сети, отчёт с приоритетами исправлений. Полный аудит с ручным тестированием API и ретестом занимает 3–5 недель в зависимости от размера кодовой базы и количества ролей. Смету под конкретный проект Applications.kz готовит за 24 часа: +7 (707) 928-13-15.

Нужен ли пентест обычному приложению, не финтеху?

Если приложение хранит персональные данные, принимает платежи или работает с корпоративной информацией — да, хотя бы один раз перед крупным запуском. Для простых каталогов и контентных приложений достаточно аудита по чек-листу OWASP и регулярного обновления зависимостей. Решение определяется ценой инцидента: чем дороже бизнесу утечка, тем глубже нужна проверка.

Можно ли сделать приложение полностью невзламываемым?

Нет, и любой, кто обещает «стопроцентную защиту», лукавит. Задача безопасности — сделать атаку дороже потенциальной выгоды: убрать секреты с клиента, зашифровать хранилище, закрыть API, усложнить реверс обфускацией. Грамотно защищённое приложение перестаёт быть лёгкой целью, и атакующие переключаются на менее защищённые продукты.