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

Самая дорогая ошибка в мобильной разработке стоит не денег на исправление, а репутации и штрафов. В 2024–2025 годах утечки через мобильные клиенты случались чаще, чем через сайты, потому что разработчики хранили токены и персональные данные на устройстве «для скорости». Ниже — практический чек-лист: что проверить до релиза, сколько стоит каждая мера и какие риски она закрывает.

Безопасность мобильного приложения — это не антивирус и не обфускация, а система из шести слоёв: устройство, канал связи, аутентификация, API, сервер и процессы команды. Провал любого слоя обнуляет остальные. Если серверный эндпоинт отдаёт данные по одному лишь user_id в запросе, шифрование на устройстве не поможет.

Ключевые выводы

• До релиза обязательны восемь проверок: хранение токенов, TLS с пиннингом, авторизация на сервере, защита API, логи, обфускация, антифрод и политика конфиденциальности.
• Проверка безопасности мобильного приложения перед релизом стоит 150–450 тыс. ₽ и занимает 2–4 недели; пентест по методике OWASP MASVS — верхняя граница вилки.
• Хранение токена в SharedPreferences или NSUserDefaults — самая частая находка аудита: данные читаются с рутованного устройства за минуты.
• Штрафы по 152-ФЗ за обработку персональных данных без согласия достигают 300 тыс. ₽ за первое нарушение и до 15 млн ₽ при повторных утечках.
• OWASP Mobile Top 10 покрывает 80% реальных атак на приложения; остальное — слабый бэкенд и человеческий фактор.
• Безопасность удорожает разработку на 8–15%, но устраняет класс инцидентов, которые стоят от 3 млн ₽ и выше.

Модель угроз: от кого вы защищаетесь

Первый шаг аудита — понять, кто ваш противник. Их четыре типа, и защита от каждого стоит по-разному.

1. Массовый автоматизированный сканер. Ищет открытые API, слабые ключи, тестовые стенды в продовой сети. Закрывается базовой гигиеной: ключи не в коде, тестовые окружения за VPN, лимиты на запросы.
2. Конкурент или исследователь с рутованным устройством. Разбирает APK, смотрит трафик, пробует подменить запросы. Против него — обфускация, проверка целостности, пиннинг сертификата, серверная авторизация.
3. Внутренний злоумышленник. Сотрудник с доступом к админке или базе. Закрывается разграничением прав, журналированием действий и хранением минимума данных.
4. Целевая атака на платёжный поток. Подмена реквизитов, возвраты, фрод. Закрывается антифродом на сервере, лимитами и обязательным подтверждением операций.

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

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

Если у вас нет платежей и персональных данных, достаточно первого и второго уровня. Если есть медицинские данные или платежи — нужны все четыре.

Хранение и передача данных: где чаще всего течёт

Утечки происходят на устройстве и в канале связи. Начните с двух вопросов — что именно я сохраняю на телефоне и что уходит в сеть. По нашей практике, 6 из 10 приложений малого и среднего бизнеса хранят токен доступа в незащищённом хранилище.

Правила, которые не обсуждаются:

• Токены и ключи — только в защищённом хранилище: Keychain на iOS, Keystore или EncryptedSharedPreferences на Android.
• База приложения с персональными данными — с шифрованием (SQLCipher), а не открытым SQLite.
• Весь трафик — по HTTPS с TLS 1.2 и выше. HTTP запрещён, включая внутренние сервисы.
• Сертификат-пиннинг для критичных API: защищает от подмены через прокси с установленным корневым сертификатом.
• Никаких персональных данных и токенов в логах, крашлитике и аналитических событиях.
• Секреты приложения (ключи платёжек, API-ключи сервисов) не хранятся в клиенте: только на сервере.
• Скриншоты и кеш изображений — отключаем для экранов с чувствительными данными.

Что проверяют в трафике

Перехват трафика на устройстве с установленным пользовательским сертификатом — стандартный приём. Утилита вроде mitmproxy или Charles показывает все запросы в открытом виде. Если вы видите в них номера карт, паспортные данные или токены сессии, релиз откладывается. Лечится пиннингом и переносом чувствительных операций на сервер.

Аутентификация и авторизация: главная разница

Аутентификация отвечает на вопрос «кто вы», авторизация — «что вам можно». Большинство взломов происходит не через подбор пароля, а через отсутствие второй проверки: сервер доверяет тому, что клиент прислал идентификатор пользователя.

Ключевое правило: каждая операция проверяется на сервере заново. Клиент может отправить order_id, но право на этот заказ сервер определяет по токену, а не по идентификатору из тела запроса. Это называется broken object level authorization — самая частая уязвимость мобильных API.

Безопасность API и бэкенда: 80% работы

Приложение — это тонкий клиент, все решения принимаются на сервере. Отсюда простая логика: если ваш бэкенд крепкий, слабый клиент не смертелен. Если наоборот, никакая защита на устройстве не спасёт.

1. Лимиты запросов. 60–120 запросов в минуту на пользователя, отдельные лимиты на отправку SMS и коды подтверждения. Без них перебор и SMS-флуд стоят вам денег.
2. Валидация на сервере. Ни одно поле из клиента не принимается без проверки типа, длины и диапазона.
3. Идемпотентность платежей. Повторный запрос на оплату не создаёт вторую транзакцию.
4. Журналирование. Логи входов, смены пароля, платежей и действий администраторов, со сроком хранения 6–12 месяцев.
5. Регулярные обновления зависимостей. Библиотека с известной уязвимостью — открытая дверь; сканирование зависимостей настраивается в CI.
6. Изоляция сред. Тестовый контур не имеет доступа к продовой базе и реальным платёжным ключам.

Отдельно про ИИ-функции

Требования к безопасности мобильного приложения с моделью внутри выше: часть данных уходит внешнему провайдеру, и это нужно описать в политике. Если приложение ещё проектируется, дешевле заложить эти правила сразу — иначе переделка авторизации и логирования обойдётся в 200–450 тыс. ₽.

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

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

Что проверить перед релизом: чек-лист

Безопасность мобильного приложения на этом этапе проверяют по списку, а не по памяти: соберите приёмку и подпишите её до публикации. Минимальный набор — 12 пунктов.

• Токены в Keychain или Keystore, кеш персональных данных зашифрован.
• HTTPS везде, пиннинг для критичных API, нет отключения проверки сертификата в релизной сборке.
• Авторизация проверяется на сервере для каждого объекта, а не на клиенте.
• Лимиты, капча и задержки против перебора и SMS-флуда.
• Обфускация кода и проверка целостности сборки для Android.
• Нет отладочных логов, тестовых учёток и заглушек в релизе.
• Платёжные ключи только на сервере, подтверждение операций с двух сторон.
• Согласие на обработку персональных данных и политика конфиденциальности в приложении и в сторах.
• Возможность удалить аккаунт и данные из приложения: требование App Store и Google Play.
• Канал для сообщений об уязвимостях и срок реакции.
• Обновление зависимостей и план обновлений безопасности минимум дважды в год.
• Инструкция для команды: что делать при утечке и кто отвечает.

Стоимость всего блока — 150–450 тыс. ₽ у внешней команды, 2–4 недели. Внутренний аудит с чек-листом дешевле, но находит в среднем на 30–40% меньше проблем: свой код читаешь с привычными слепыми зонами. Если приложение только планируется, дешевле заложить эти требования сразу — типовые ошибки этапа описаны в материале как создать приложение.

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

Обязателен ли пентест для мобильного приложения?

По закону — нет, если вы не государственная система и не финансовая организация. По практике — да, если в приложении платежи, персональные данные или медицинская информация. Пентест стоит 250–450 тыс. ₽ и занимает 3–4 недели, но находит проблемы до того, как их найдёт кто-то другой.

Сколько стоит защитить приложение от утечек?

Базовая гигиена — часть разработки и стоит 8–15% бюджета проекта: для приложения за 2,5 млн ₽ это 200–380 тыс. ₽. Внешний аудит перед релизом — 150–450 тыс. ₽. Ежегодные проверки и обновления — 120–250 тыс. ₽ в год.

Нужно ли хранить данные пользователей на устройстве?

Храните минимум: только то, без чего приложение не работает офлайн. Идеальный вариант — держать на сервере, а на телефоне кешировать обезличенные фрагменты. Если офлайн обязателен, шифруйте локальную базу и очищайте данные при выходе из аккаунта.

Что грозит за утечку персональных данных?

Для оператора персональных данных — штрафы по 152-ФЗ, которые в 2025 году выросли: до 300 тыс. ₽ за первое нарушение и кратно больше при повторных, включая оборотные штрафы за утечки. Дальше — иски пользователей, проверки и потеря корпоративных клиентов, которые требуют от подрядчиков подтверждённый уровень защиты.

Как часто нужно проверять безопасность после релиза?

Полный аудит — раз в год или перед крупным релизом. Сканирование зависимостей и проверку конфигураций — на каждой сборке в CI. Пересмотр прав доступа — раз в квартал: люди уходят, а их учётные записи остаются.

Что делать дальше

Безопасность мобильного приложения дешевле встроить в разработку, чем исправлять после инцидента: исправление всегда дороже профилактики в 3–5 раз.

Начните с инвентаризации данных: выпишите, какие сведения приложение собирает, где хранит и кому передаёт. Дальше закройте три базовых пункта — защищённое хранилище токенов, пиннинг сертификата и серверная авторизация. Это 60–120 тыс. ₽ работ, если делать в рамках текущего спринта, и они снимают большую часть реальных рисков.

Проверяют безопасность не по ощущениям, а по отчёту: закажите внешнюю проверку кода и API с документом, где каждая находка размечена по критичности. Если создание мобильного приложения только планируется, требования из чек-листа дешевле включить в техническое задание сразу. Если проект только начинается, создать мобильного приложения с нуля дешевле вместе с этим чек-листом: аудит включают в первый спринт; если продукт уже работает, его заказывают отдельным этапом у команды, которая ведёт разработку мобильного приложения: разработка приложений — это и код, и инфраструктура, и процессы релиза. Полезно заранее прочитать про данные и 152-ФЗ и про требования сторов в материале публикация в App Store: часть отказов модерации связана именно с приватностью и обработкой данных.

Статья основана на практике проектов НейроДела и данных Яндекс Вордстата по кластеру «Разработка приложений». Основной запрос материала — «безопасность мобильного приложения» (5 623 показов в месяц). Если у вас другая ситуация — напишите, разберём.