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

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

Серверную часть — хранение паролей, роли, резервные копии, журналы — мы разобрали в статье о безопасности веб-приложения: у приложения обычно тот же сервер, и те вопросы остаются в силе. Здесь только то, что относится к телефону и к сборке.

Чем безопасность приложения отличается от безопасности сайта?

Сайт целиком работает на вашем сервере, а приложение — наполовину в чужих руках. Сборку скачивает каждый, её можно разобрать на компьютере, запустить на взломанном телефоне и подсмотреть обмен с сервером. Всё, что лежит внутри сборки или на устройстве, считайте потенциально видимым.

Отсюда главное правило, которое стоит услышать от подрядчика: приложение — это витрина, а решения принимает сервер. Цена товара, размер скидки, права пользователя, факт оплаты проверяются на сервере при каждом запросе. Если приложение само решает «показать премиум-раздел, потому что флажок в памяти равен единице», флажок поменяют.

Вторая особенность — обновления: сайт исправили за минуту, а приложение обновляется через магазин, и часть пользователей месяцами сидит на старой версии вместе с её уязвимостью.

Что такое OWASP MASVS простыми словами?

MASVS — открытый стандарт требований к безопасности мобильных приложений от некоммерческого проекта OWASP. В версии 2.1.0 от января 2024 года в нём 8 групп и 24 контроля: хранение, шифрование, вход, сеть, взаимодействие с системой, качество кода, защита от разбора и приватность.

Заказчику он полезен как общий язык: вместо «сделайте безопасно» в ТЗ пишут «соответствие MASVS по профилю L1». Уровни строгости вынесены в профили проверки руководства MASTG:

• MAS-L1 — базовая безопасность: угрозой считаются другие приложения на том же телефоне;
• MAS-L2 — повышенная: системе телефона доверять нельзя, у злоумышленника может быть физический доступ к устройству;
• MAS-R — защита от разбора и подмены, когда атакует сам пользователь; по описанию OWASP она дополняет L1 или L2 и отдельно не применяется;
• MAS-P — базовая защита персональных данных пользователя.

Первоисточник — сайт проекта OWASP MAS, описание профилей — в разделе MAS Testing Profiles. Стандарт англоязычный и сертификатом не является: это чек-лист, а не печать.

Группа	О чём она	Вопрос на языке бизнеса
STORAGE	Хранение данных на телефоне	Что останется в памяти, если телефон украдут или продадут?
CRYPTO	Шифрование и ключи	Не придумывает ли разработчик своё шифрование?
AUTH	Вход и права	Можно ли войти чужим токеном и что проверяет сервер?
NETWORK	Связь с сервером	Можно ли подслушать или подменить обмен данными?
PLATFORM	Взаимодействие с системой	Что видят другие приложения, клавиатура, экран многозадачности?
CODE	Качество кода и обновления	Как быстро закрыть дыру у пользователей старых версий?
RESILIENCE	Защита от разбора и подмены	Насколько трудно распаковать сборку и сделать «взломанную» копию?
PRIVACY	Приватность	Не собирает ли приложение больше, чем нужно, и знает ли об этом пользователь?

Где приложение хранит токены и пароли?

В системных хранилищах секретов: на iPhone это Keychain, на Android — данные, зашифрованные ключом из Android Keystore. Пароль пользователя на телефоне не хранится вовсе: после входа сервер выдаёт токен, и приложение держит только его.

Частая проблема кроссплатформенных и гибридных приложений — токен в обычных настройках или в локальном хранилище веб-слоя. Так быстрее написать, и на демонстрации разницы не видно. Но такие файлы попадают в резервные копии телефона и читаются на устройстве с правами суперпользователя. Для React Native, Flutter и Capacitor есть плагины, работающие с Keychain и Keystore, — вопрос только в том, использует ли их подрядчик.

Что ещё спросить в этом блоке:

• Срок жизни токена. Короткий токен доступа плюс токен обновления, который сервер может отозвать. Вечный токен, выданный один раз, — плохой признак.
• Кеш данных. Каталог и картинки можно хранить открыто, историю заказов с адресами и чеки — с той же осторожностью, что и токен, или не хранить совсем.
• Вход по отпечатку или лицу. Биометрия должна открывать доступ к токену в хранилище, а не просто показывать экран после «успешной проверки».

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

Любые секреты, которые дают права на ваши деньги и данные: ключ платёжного сервиса, токен SMS-шлюза, пароль к базе, служебный ключ облачного хранилища. Из сборки их достают за вечер стандартными инструментами, и обфускация это не меняет.

В приложении допустимы только ключи, рассчитанные на публичное использование: идентификатор проекта для push-уведомлений, ключ карт или аналитики с ограничением по идентификатору вашего приложения. Всё остальное приложение получает через свой сервер: оно просит «отправь код на этот номер», а сервер сам ходит в SMS-шлюз со своим ключом и сам ограничивает частоту отправки.

Простой тест: спросите, что сможет сделать конкурент, достав из сборки все строки. Если «отправлять SMS за ваш счёт» — архитектуру меняют до выпуска.

Как приложение проверяет, что говорит с вашим сервером?

Весь обмен должен идти по HTTPS с полной проверкой сертификата. iOS по умолчанию требует защищённого соединения через App Transport Security, приложения под Android 7.0 и новее по умолчанию не доверяют сертификатам, которые пользователь установил сам. Опасность в том, что эти защиты можно отключить одной строкой в настройках сборки.

Попросите показать конфигурацию: на iOS — нет ли исключений App Transport Security, на Android — файл сетевой конфигурации. Исключения «для тестового сервера» и отключённая проверка сертификата из-за ошибки на стенде регулярно доезжают до релиза.

Следующий уровень — закрепление сертификата (certificate pinning): приложение знает отпечаток ключа вашего сервера и не доверяет никому другому, даже «правильно» выпущенному сертификату. Это затрудняет перехват трафика, но у меры есть цена. Документация Android советует всегда держать резервный ключ: иначе при смене ключа сервера приложение потеряет связь, пока пользователи не обновятся. Поэтому закрепление разумно для приложений с платежами и ценными данными, а для каталога или записи в салон чаще избыточно.

Что приложение пишет в логи и показывает в фоне?

В релизной сборке логи должны быть урезаны, а телефоны, токены, адреса и содержимое запросов туда не попадают совсем. Google в руководстве по безопасности Android напоминает, что логи — общий ресурс устройства, и просит не писать в них персональные данные.

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

Ещё три места, о которых редко думают:

• Превью в многозадачности. Система делает снимок экрана, когда приложение уходит в фон. Для экранов с балансом, документами или медицинскими данными его скрывают; на Android для этого есть флаг защищённого окна, он же запрещает скриншоты.
• Push-уведомления. Текст виден на экране блокировки. Коды входа, суммы и диагнозы туда не пишут: «У вас новое сообщение» безопаснее содержимого.
• Буфер обмена и клавиатура. Поля с кодами и паролями помечают так, чтобы сторонняя клавиатура не запоминала ввод.

Какие разрешения и сторонние SDK нужны приложению?

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

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

Нужна ли защита от рута, джейлбрейка и обфускация?

Не всегда. Это профиль MAS-R: он усложняет разбор и подмену приложения, но не заменяет базовых мер. Нужен там, где взломанная копия приносит прямой ущерб: деньги, бонусы, платный контент, игры с внутренней валютой, корпоративные данные.

Что входит в этот слой:

• Обфускация. Код в релизной сборке переименовывается и запутывается. Ключи это не спрячет, но разбор логики станет дороже. Важная деталь: карту обфускации хранят, иначе отчёты о сбоях станут нечитаемыми.
• Проверка устройства. Приложение замечает права суперпользователя, отладчик или изменённую сборку. Надёжнее проверять это на сервере через сервисы платформ — Play Integrity API у Google и App Attest у Apple, — чем только на телефоне, где проверку можно отключить.
• Реакция. Это бизнес-решение, а не техническое: предупредить, отключить оплату или не пускать совсем. Блокировка всех рутованных телефонов отрежет часть честных пользователей и даст поток отзывов на одну звезду.

Что происходит при выходе, смене телефона и удалении аккаунта?

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

Проверка на тестовой сборке: войти, выйти и повторить старый запрос с прежним токеном — сервер должен отказать. Полезна и кнопка «выйти на всех устройствах». Удаление аккаунта из приложения — отдельное требование App Store и Google Play; что именно они требуют, разобрано в статье о персональных данных, повторять здесь не будем.

Кто владеет ключом подписи и как выпускаются срочные исправления?

Ключи подписи и аккаунты в магазинах должны быть на заказчике. Если ключ Android-сборки есть только у одного разработчика, выпуск исправления зависит от его ноутбука, а потеря ключа без подписи через Google Play может означать новое приложение вместо обновления.

Второй вопрос — как заставить пользователей обновиться, если в старой версии нашли дыру. Хороший ответ: приложение при запуске спрашивает у сервера минимальную допустимую версию и просит обновиться, если его версия ниже. Добавить его можно только в новые версии, поэтому закладывают сразу. Как устроены аккаунты и ключи — в статье об аккаунтах разработчика Apple и Google Play.

12 вопросов к подрядчику: сводная таблица

Задайте эти вопросы до договора или хотя бы до приёмки. Важна конкретность: подрядчик называет хранилище, библиотеку, файл конфигурации и показывает это на тестовой сборке. Функциональную проверку добавьте из статьи о проверке приложения перед релизом.

Вопрос	Хороший ответ	Тревожный ответ
1. Где на телефоне лежит токен входа?	В Keychain на iOS, ключом из Android Keystore на Android	«В настройках приложения» или «в локальном хранилище»
2. Что ещё приложение сохраняет на устройстве?	Называют конкретные данные и как они защищены	«Ничего особенного, кеш»
3. Какие ключи и пароли есть внутри сборки?	Только публичные ключи сервисов с ограничениями; секреты — на сервере	«Ключ платёжки в коде, но код же скомпилирован»
4. Весь ли обмен идёт по HTTPS?	Да, исключений для HTTP нет, в том числе для картинок и SDK	«Для тестового сервера оставили HTTP, потом уберём»
5. Нужно ли закреплять сертификат сервера?	Объясняют, когда да, и про резервный ключ	Отключённая проверка сертификата «чтобы работало»
6. Что попадает в логи и отчёты о сбоях?	В релизе логи урезаны, телефоны и токены не пишутся	«Логи помогают отлаживать, пусть будут»
7. Что видно в превью и на экране блокировки?	Чувствительные экраны скрываются, в push нет кодов и сумм	Вопрос раньше не задавали
8. Зачем каждое разрешение и каждый SDK?	Список с целью для каждого пункта	«Это шаблон проекта, так у всех»
9. Что будет на рутованном телефоне?	Решение принято под риск: предупреждение, ограничение или ничего	«Мы блокируем всё, никто не взломает»
10. Обфусцирован ли релизный код?	Да, где есть что прятать; карта для расшифровки сбоев хранится	«Обфускация — это и есть защита»
11. Что происходит при выходе из аккаунта?	Токен отзывается на сервере, локальные данные стираются	Выход только «прячет» экраны
12. Как выпустить срочное исправление?	Ключи подписи на вашем аккаунте, есть механизм обязательного обновления	«Ключ у нашего разработчика на ноутбуке»

Когда нужен внешний аудит мобильного приложения?

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

Что важно знать о таком аудите:

• Проверяют связку. Аудитору дают и сборку, и тестовый сервер: половина находок в мобильных приложениях — на стыке с API.
• Профиль задают заранее. «Проверить по MASVS, профиль L1» или «L2 плюс R» — так результаты двух аудиторов можно сравнить, а отчёт не превращается в список общих советов.
• Отчёт — план работ. Заранее договоритесь, кто и в какие сроки исправляет найденное; после крупных изменений аудит повторяют.
• Автоматические сканеры сборок дешевле: находят ключи в коде и лишние разрешения, но почти не видят логических ошибок вроде «скидка считается на телефоне».

Стоимость аудита называет компания, которая его проводит, — запрашивайте смету на конкретную сборку и профиль.

Когда это избыточно и какие ошибки встречаются чаще всего?

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

Типичные ошибки, которые всплывают при проверке готовых приложений:

• ключ платёжного сервиса или SMS-шлюза внутри сборки;
• токен в обычных настройках, без срока жизни и без отзыва при выходе;
• цена, скидка или доступ к платному разделу проверяются только на телефоне;
• отключённая проверка сертификата, оставшаяся со времён тестового стенда;
• подробные логи и отчёты о сбоях с телефонами клиентов в релизной версии;
• нет механизма обязательного обновления, и уязвимую версию нельзя отключить;
• ключ подписи Android есть только у прежнего разработчика.

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

Как это устроено у нас?

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

Тариф «Мобильное приложение» — от 200 000 ₽, от 2 недель: iOS и Android из одного кода или PWA, до 6–8 экранов, вход, push, оплаты, подключение к вашему API или простой сервер. Аккаунты разработчика Apple и Google Play оформляются на вас, исходный код — в вашем репозитории, доступы ко всем сервисам передаём. Защиту от разбора, проверку устройства через сервисы платформ и подготовку к внешнему аудиту считаем после брифа. После публикации — 14 дней бесплатной поддержки и гарантия 30 календарных дней с даты акта по договору; обновления дальше — в поддержке от 7 900 ₽ в месяц.

Пример из наших работ — приложение знакомств Twin: единый код на React, нативные сборки для iOS и Android через Capacitor, чат на WebSocket и коды подтверждения на почту.

Короткие ответы на частые вопросы

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

Нет. Сборку на телефоне пользователя можно распаковать и изучить, поэтому цель — чтобы из неё нельзя было достать секреты, а все важные проверки шли на сервере. Защита от разбора только повышает стоимость атаки.

Что такое OWASP MASVS?

Открытый стандарт требований к безопасности мобильных приложений от проекта OWASP: 8 групп и 24 контроля в версии 2.1.0. К нему прилагаются руководство по тестированию и профили проверки L1, L2, R и P.

Где правильно хранить токен авторизации в приложении?

На iOS — в Keychain, на Android — в зашифрованном виде с ключом из Android Keystore. Обычные настройки приложения и локальное хранилище веб-слоя для этого не подходят.

Обязательно ли закреплять сертификат сервера (certificate pinning)?

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

Нужен ли пентест перед первым выпуском в магазины?

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

Услуги и кейсы по теме: мобильные приложения · кейс Twin · цены и сроки