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

По данным IBM, средняя стоимость утечки данных в 2025 году составила $4,44 млн, а отчет Verizon DBIR отмечает рост инцидентов у малого и среднего бизнеса: такие компании атакуются почти в 4 раза чаще крупных.

Так, в июле 2025 года дейтинг-платформа Tea столкнулась с масштабной утечкой данных: хакеры получили доступ к 72 тысячам изображений пользователей, включая удостоверения личности. Инцидент показал: быстрорастущие consumer-приложения могут стать источником серьезных утечек при недостаточной зрелости процессов хранения и защиты данных.

Меня зовут Юлия Мицкевич, я операционный директор в IT-компании KODE. В материале — пять неочевидных уязвимостей мобильных приложений и способы предотвратить их на уровне процессов и решений.

Сторонние SDK и транзитивные библиотеки, незаметно собирающие пользовательские данные

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

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

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

Хранение API-ключей на стороне клиента

API-ключи и другие служебные секреты (токены, client secrets, пароли сервисов) обеспечивают приложению доступ к внутренним системам компании. Их разработчики размещают прямо в коде — внутри Android- или iOS-пакета, JavaScript-bundle или конфигурационных файлов.

Такой подход создает риски: злоумышленник может извлечь эти данные из клиентского приложения и использовать их для несанкционированных действий — например, выполнять запросы напрямую к API или инициировать операции от имени компании. Подобные инциденты фиксируются регулярно: при автоматическом поиске в открытых источниках (GitHub, VirusTotal, Shodan) обнаруживаются тысячи активных ключей, которые затем используются для фрода и кражи данных. Один скомпрометированный ключ способен дать доступ к информации всех пользователей и нанести компании финансовый и репутационный ущерб.

Чтобы минимизировать риски, привилегированные ключи стоит хранить на серверной стороне, использовать короткоживущие токены (short-lived tokens) и регулярно проводить проверку репозиториев на наличие выложенных секретов.

Проблема SSL-сниффинга (TLS/MITM)

SSL-сниффинг, или атака типа man-in-the-middle (MITM), возникает, когда злоумышленник перехватывает или изменяет сетевой трафик между мобильным приложением и сервером, несмотря на защищенное соединение. Такие атаки возможны в публичных сетях Wi-Fi, при использовании корпоративных прокси или скомпрометированных точек доступа.

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

Для предотвращения подобных инцидентов необходимо применять современные версии TLS, обеспечивать обязательную проверку сертификатов в производственных сборках, использовать механизм certificate pinning во всех сценариях. Также стоит внедрять краткосрочные токены и многофакторную аутентификацию при операциях с чувствительными данными. Стоимость внедрения этих мер несопоставимо ниже потенциальных потерь от одной успешной MITM-атаки.

Низкий уровень защиты журналов и систем мониторинга

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

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

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

WebView, JavaScript-бриджи и кастомные URI-схемы как векторы обхода защитных границ

WebView используется для быстрой интеграции веб-контента в мобильное приложение — например, для демонстрации промо-страниц, форм оплаты или внешнего контента. Такой подход экономит ресурсы разработки, но и открывает приложение для внешнего кода: если встраиваемая страница выполняет JavaScript или предоставлен двусторонний мост (например, через addJavascriptInterface), у внешнего контента появляется возможность взаимодействовать с нативной частью приложения и получать доступ к данным.

Аналогично, нестандартизованные или небезопасно реализованные кастомные URI-схемы (myapp://) могут быть вызваны из внешних источников и инициировать действия, которые приложение считает легитимными.

К использованию WebView стоит подходить с ответственностью: оценивать содержание загружаемых страниц, ограничивать источники контента (whitelist), запрещать выполнение произвольного JavaScript для критичных флоу и избегать использования WebView в сценариях с авторизацией, платежами или доступом к профилю пользователя.

Чек-лист для бизнеса: как выстроить систему защиты данных

1. Установите продуктовые стандарты безопасности. Безопасность должна быть зафиксирована на уровне продукта, а не только разработки. Пропишите, какие данные допустимо собирать и хранить, кто несет ответственность за их обработку, что считается нарушением. Это позволит измерять уровень защищенности так же, как ключевые бизнес-метрики.
2. Назначьте ответственных и распределите зоны контроля. Определите, кто утверждает использование SDK, кто отвечает за хранение ключей, кто контролирует логи и мониторинг. Формализованные роли превращают безопасность в управляемый процесс с понятными KPI.
3. Сформируйте культуру устойчивого роста. Быстрые релизы — конкурентное преимущество, но они должны сочетаться с проверками на критичных этапах. Аудит SDK, валидация ключей и анализ логов должны быть встроены в рабочие спринты как часть цикла разработки.
4. Проводите регулярный аудит с практическими целями. Независимая проверка помогает выявить системные уязвимости, которые не видны изнутри.
5. Рассматривайте безопасность как часть экономики продукта. Утечка данных — это угроза финансовым показателям и капитализации. Включайте расходы на аудит и профилактику в unit-экономику продукта: оцените стоимость минуты простоя, восстановления доверия и потери клиентов при инциденте.