Мобильное приложение кажется чем-то аккуратным и закрытым: красивый интерфейс, кнопочки, авторизация, API, пуши, экран профиля. Всё выглядит спокойно.
Но есть нюанс: приложение живёт не только на твоём сервере. Оно устанавливается на устройство пользователя. А значит, его можно изучать, разбирать, перехватывать запросы и проверять, что там разработчик случайно оставил внутри.
И если внутри лежат API-ключи, токены, секреты или проверка premium-доступа уровня if (isPremium), то где-то в мире уже улыбается человек с Frida, Burp Suite и слишком большим количеством свободного времени.
Почему мобильные приложения вообще взламывают?
Потому что мобильное приложение — это не магическая коробка. Это код, который пользователь буквально получает себе на устройство.
Его можно:
декомпилировать;
изучить сетевые запросы;
посмотреть, где хранятся данные;
найти API-эндпоинты;
попробовать подменить ответы сервера;
модифицировать APK или IPA;
обойти клиентские проверки.
Разработчик думает: «Да кому нужно моё приложение?»
А реальность отвечает: «Ботам, конкурентам, любителям халявного premium и людям, которые просто решили потренироваться».
Что могут украсть из мобильного приложения?
1. API-ключи
Это одна из самых популярных ошибок. Разработчик кладёт ключ прямо в приложение, потому что «ну а куда ещё?».
const API_KEY = "super_secret_key_123";Проблема в том, что если ключ находится в клиентском приложении, его потенциально можно достать. Даже если код обфусцирован. Даже если переменная называется не API_KEY, а x7a_qwerty_final_final2.
Особенно опасно хранить в приложении ключи от:
платёжных сервисов;
облачных хранилищ;
LLM/API-сервисов;
картографических сервисов;
админских методов backend;
внутренних интеграций.
В худшем случае кто-то начинает использовать твой ключ, а счёт приходит тебе. Очень бодрит. Особенно утром.
Как защититься?
Не хранить секретные ключи в мобильном приложении.
Всё критичное проксировать через backend.
Ограничивать ключи по правам, доменам, IP и лимитам.
Следить за использованием ключей и быстро отзывать скомпрометированные.
2. Токены пользователей
Токен авторизации — это билет в аккаунт пользователя. Если его украли, злоумышленник может делать запросы от имени человека.
Типичная ошибка:
localStorage.setItem("token", token);Или мобильный аналог: положить чувствительные данные в обычное хранилище без защиты.
Для мобильных приложений лучше использовать:
Keychain на iOS;
Keystore на Android;
защищённые хранилища фреймворков, если они действительно используют системные механизмы защиты.
И да, не стоит логировать токены. Даже «временно». Потому что временный console.log(token) живёт дольше некоторых стартапов.
3. Персональные данные
В мобильном приложении могут храниться имена, телефоны, email, адреса, история заказов, сообщения, фотографии, документы и другие данные пользователя.
Если приложение хранит это небезопасно, то проблема уже не только техническая. Это репутация, юридические риски и тот самый неприятный момент, когда хочется выключить интернет и уехать в лес.
Что важно делать?
Не хранить лишнее на устройстве.
Шифровать чувствительные данные.
Очищать кэш, если он содержит приватную информацию.
Не отправлять персональные данные в аналитику без необходимости.
Следить за сторонними SDK.
4. Premium-доступ и покупки
Самая мемная ошибка — проверять подписку только на клиенте.
if (user.isPremium) {
unlockAllFeatures();
}На первый взгляд всё логично. Пользователь premium — открываем функции.
Но если решение принимается только на устройстве, его можно попробовать изменить. Подменить ответ API, модифицировать приложение, отключить проверку, заменить значение.
Клиенту нельзя доверять. Вообще. Никогда.
Сервер должен быть главным источником правды:
есть ли подписка;
какой тариф активен;
можно ли открыть функцию;
валидна ли покупка;
не истёк ли доступ.
Клиент может красиво показать кнопку. Но решать, можно ли пользователю получить доступ, должен backend.
5. Сетевые запросы
Мобильное приложение постоянно общается с сервером. Авторизация, профиль, лента, покупки, сообщения, пуши, аналитика — всё это запросы.
Если их перехватить, можно увидеть:
какие эндпоинты используются;
какие данные отправляются;
какие заголовки нужны;
как устроена авторизация;
какие ответы возвращает сервер.
HTTPS обязателен, но одного HTTPS не всегда достаточно. Для более серьёзной защиты используют SSL Pinning.
Что такое SSL Pinning?
SSL Pinning — это проверка, что приложение общается именно с нужным сервером, а не с кем-то посередине.
Без SSL Pinning злоумышленник может попытаться настроить прокси и смотреть трафик приложения через инструменты вроде Burp Suite или Charles Proxy.
С SSL Pinning приложение становится подозрительным: «Так, сертификат какой-то не тот. Я с тобой разговаривать не буду».
Но делать SSL Pinning нужно аккуратно. Если всё завязать слишком жёстко, можно случайно сломать приложение после обновления сертификата.
Reverse Engineering: когда твоё приложение читают как книгу
Reverse Engineering — это разбор приложения, чтобы понять, как оно работает внутри.
С помощью декомпиляции и анализа можно найти:
строки с URL;
названия методов;
ключи;
условия проверок;
логику premium-доступа;
скрытые функции;
debug-информацию.
Обфускация помогает усложнить жизнь атакующему. Она не делает приложение бессмертным, но превращает чтение кода из «приятной прогулки» в «зачем я вообще в это полез».
Что использовать?
ProGuard/R8 для Android;
минимизацию и обфускацию JS-кода для React Native;
удаление debug-логов;
проверку целостности приложения;
защиту от запуска в подозрительной среде.
Root и Jailbreak
На root/jailbreak-устройствах пользователь получает больше контроля над системой. А значит, больше возможностей вмешиваться в работу приложения.
Можно:
читать файлы приложения;
перехватывать данные;
подменять поведение;
использовать инструменты динамического анализа;
вмешиваться в память процесса.
Проверка root/jailbreak не даёт абсолютной защиты. Её тоже обходят. Но она повышает стоимость атаки и помогает отсеять часть простых сценариев.
Сторонние SDK: бесплатный сыр в красивой обёртке
Аналитика, реклама, пуши, crash reports, авторизация, платежи — мобильные приложения часто используют много сторонних SDK.
И каждый SDK — это дополнительный риск.
Он может:
собирать больше данных, чем нужно;
иметь уязвимости;
тянуть старые зависимости;
конфликтовать с политиками магазинов;
увеличивать поверхность атаки.
Поэтому SDK нужно выбирать не по принципу «о, тут красивая документация», а хотя бы немного смотреть, что именно он делает.
Минимальный чек-лист безопасности
Если коротко, нормальная база для мобильного приложения выглядит так:
не хранить секретные ключи в приложении;
использовать HTTPS;
добавить SSL Pinning для критичных запросов;
хранить токены в Keychain/Keystore;
не логировать чувствительные данные;
проверять права доступа на backend;
обфусцировать код;
удалять debug-функции из production-сборки;
следить за сторонними SDK;
проверять root/jailbreak, если приложение работает с чувствительными данными;
ограничивать API-ключи и токены по правам;
регулярно обновлять зависимости.
Главное правило: клиенту нельзя доверять
Это база мобильной безопасности.
Клиент может быть модифицирован. Запрос может быть подменён. Ответ может быть изменён. Устройство может быть взломано. Пользователь может быть не тем, кем кажется.
Поэтому вся критичная логика должна жить на сервере.
Мобильное приложение — это интерфейс. Backend — это охранник. И если охранник спит, красивый интерфейс уже не спасёт.
Кстати, если хочешь прокачиваться в разработке
В приложении «Кодик» можно изучать программирование через практику: проходить задания, повторять темы и постепенно разбираться в том, как реально устроена разработка.
А ещё у нас есть Telegram-сообщество, где выходят полезные посты для разработчиков: про frontend, backend, мобильную разработку, безопасность, архитектуру, инструменты и всякие штуки, которые помогают не просто писать код, а понимать, что происходит под капотом.
Это удобный способ возвращаться к программированию каждый день без ощущения, что ты снова открыл скучный учебник на 900 страниц.