Чеклист безопасности Android-приложения перед публикацией в Google Play

1. Опишите данные и роли

Начните не с инструментов, а с простого списка. Какие данные собирает приложение?

• имя, email, телефон и адрес;
• статус оплаты, история заказов или геолокация доставки;
• фотографии, файлы или сообщения;
• медицинская, wellness- или идентификационная информация;
• заметки поддержки, действия администратора, выплаты провайдерам.

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

2. Уберите секреты из приложения

Все, что попало в Android-приложение, можно исследовать. Нельзя хранить внутри приложения приватные API-ключи, админские токены, платежные секреты, доступы к базе данных или ключи подписи.

Нормальные подходы:

• платежи и привилегированные действия проходят через сервер;
• токены по возможности живут недолго;
• публичные ключи SDK считаются публичными;
• случайно раскрытые ключи быстро меняются;
• в релизной сборке нет тестовых адресов и debug-флагов.

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

3. Сократите разрешения

Пользователи замечают запросы разрешений, а Google Play внимательно относится к чувствительным разрешениям. Запрашивайте только то, что реально нужно, и делайте это в момент пользы, а не сразу после открытия приложения.

Проверьте:

• геолокация: точная или примерная, в приложении или в фоне;
• камера и доступ к медиа;
• контакты и календарь;
• разрешение на уведомления;
• микрофон и Bluetooth;
• специальные разрешения, которым нужно сильное обоснование.

Если функция MVP может работать без чувствительного разрешения, лучше не добавлять его. Лишние разрешения снижают доверие и могут усложнить проверку.

4. Защитите локальное хранение

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

Проверьте:

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

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

5. Проверьте сеть и серверный доступ

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

Проверьте:

• API работает по HTTPS;
• пользователь видит только свои записи;
• роли провайдера и администратора проверяются на сервере;
• рискованные действия имеют ограничения;
• загрузка файлов проверяется;
• статус оплаты подтверждается на сервере;
• ошибки не раскрывают лишние детали.

Для маркетплейсов и доставки отдельно смотрите владельца заказа, видимость адреса и действия провайдера.

6. Авторизация и восстановление доступа

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

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

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

7. Проверьте SDK, логи и аналитику

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

Перед релизом:

• удалите неиспользуемые SDK;
• проверьте требования SDK по приватности;
• убедитесь, что события аналитики не содержат личные данные, токены и приватный текст;
• проверьте crash-логи на чувствительные значения;
• отключите подробные debug-логи в релизной сборке.

Аналитика должна помогать улучшать продукт, а не превращать приватные данные в шум.

8. Play Integrity - когда есть смысл

В документации Android есть инструменты вроде Play Integrity API и Credential Manager. Не каждому MVP они нужны в одинаковом объеме, но приложения с платежами, риском злоупотреблений, платным контентом или маркетплейс-сценариями должны хотя бы обсудить такую защиту.

Сигналы целостности - это не волшебная стена. Серверные проверки прав и мониторинг все равно остаются обязательными.

9. Тестируйте именно релизную сборку

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

Пройдите:

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

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

Стоимость и объем

Объем безопасности зависит от данных и сценариев. Контентное MVP отличается от доставки, медицины, приватного чата или маркетплейса с выплатами.

Для российского локаля у Appfyl MVP обычно начинается примерно от 1 до 1,5 млн рублей. Средний проект чаще попадает в диапазон 1,5-3,5 млн рублей. Большое приложение с платежами, ролями, админ-панелью, чувствительными данными, мониторингом и более глубокой проверкой может стоить 3,5-6 млн рублей.

Безопасность - одна из причин оценивать проект по сценариям и рискам, а не по количеству экранов. Эти сценарии можно описать в брифе Appfyl для оценки приложения.

Как Appfyl подходит к безопасности Android

Мы держим первую версию практичной. Цель основателя - не купить все инструменты безопасности, а не допустить ошибок, которые дорого исправлять после запуска.

Обычно проверяем:

• чувствительные данные и роли;
• права на сервере;
• разрешения приложения и локальное хранение;
• платежи, бронирования или статусы заказов;
• аналитику и логи;
• поведение релизной сборки перед загрузкой в стор.

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

Посмотрите, как Appfyl превращает объем работ в запущенные продукты. Смотреть кейсы Appfyl.

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