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

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

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

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

Когда применять

Проверка нужна, если приложение работает с персональными данными, документами, заявками, платежами, внутренними системами, корпоративными устройствами, ролями сотрудников или доступом без сети.

Особенно важно пройти чек-лист до публикации в магазинах приложений, перед пилотом у заказчика, после смены подрядчика, перед подключением средств управления устройствами и приложениями или перед передачей приложения в поддержку.

Что подготовить до проверки

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

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

Порядок проверки

1. Выберите критичный пользовательский сценарий и запишите разрешённый результат: какие данные доступны и какие действия допускает роль.
2. Выполните разрешённый сценарий на согласованной сборке. Затем проверьте запрещённый вариант и убедитесь, что отказ не сопровождается раскрытием данных или изменением на сервере.
3. Проверьте, что остаётся на устройстве после выхода, смены пользователя и перехода в фоновый режим. Для приложения с автономной работой отдельно согласуйте правила доступа к локальным данным.
4. Сопоставьте ответы API с содержимым экрана, локального хранилища, журналов и диагностических пакетов. Скриншот интерфейса не подтверждает поведение остальных слоёв.
5. Для проблемы сохраните условия, шаги, фактический результат и затронутые данные. Для непроверенного сценария отметьте ограничение, а не успешное прохождение.
6. После исправления повторите запрещённый сценарий и разрешённый контрольный тест на версии, предназначенной для поставки.

Проверка по слоям

Серверную часть проверяют отдельно от защиты мобильного клиента: карта проверки безопасности API задаёт области риска, а проверка авторизации API — сценарии доступа к данным, полям и операциям.

• Доверять мобильному клиенту

  Клиент можно анализировать, модифицировать и запускать в нестандартной среде. Критичные проверки должны подтверждаться сервером.

• Хранить токены как обычные строки

  Обычные настройки приложения, открытая SQLite-база, файлы и отладочные журналы не подходят для секретов и длительно живущих токенов.

• Проверять только собственный код

  Риски часто приходят через SDK, уведомления, аналитику, сбор отчётов о сбоях, разрешения и настройки окружений.

• Забыть про эксплуатацию

  После запуска нужны отзыв доступа, повторные проверки безопасности, обновление SDK и правила безопасной диагностики.

Такой чек-лист помогает определить покрытие, но не заменяет углублённый анализ кода, тестирование серверного контура или проверку требований к обработке персональных данных. Невозможность исследовать хранилище, настройки поставки или ответы сервера должна оставаться явным ограничением результата.

Артефакты и решение о выпуске

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

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

Условный пример выхода и смены пользователя

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

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

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

Соберите карту данных, критичных действий, API-методов, ролей, локального хранилища, SDK и диагностических потоков. После этого можно определить границы проверки: мобильный клиент, клиент вместе с API или полный контур приложения, сборки и сопровождения.

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

Источники и соседние практики

Для глубокой проверки используйте OWASP MASVS ↗, OWASP Mobile Top 10 ↗, MASVS-STORAGE ↗, Android security checklist ↗, Android Keystore ↗ и Apple Security Overview ↗.

Если нужно сначала понять общую рамку темы, откройте обзорный материал «Безопасность мобильных приложений».