strings app.apk | grep -i "key\|secret\|token" — эта команда в большинстве приложений без защиты выводит несколько секретов. Google Maps API Key в AndroidManifest.xml, Firebase API Key в google-services.json, Stripe Publishable Key в исходном коде — всё это извлекается из APK без реверс-инжиниринга. Мы сталкивались с проектами, где ключи лежали прямо в коде, и их видел любой скачавший приложение.
Почему нельзя хранить ключи в коде?
Любой ключ, встроенный в ресурсы или константы, — публичный. APK и IPA декомпилируются; обфускация лишь усложняет поиск, но не предотвращает. Например, ключ в local.properties всё равно попадает в билд и читается из манифеста. Google Maps API Key можно ограничить по package name и SHA-1, но для настоящих секретов (ключа платежного шлюза) это не выход.
Часто слышат: «Firebase API Key публичный, его можно засветить». Технически верно для apiKey — он идентифицирует проект, доступ контролируется Firebase Rules. Но Maps Key, Stripe Secret Key, ключи к бэкенду — другое. Утечка Maps Key грозит чужими запросами за ваш счет. Мы гарантируем, что после нашей работы ключи никогда не покинут устройство без необходимости, а серверные секреты останутся на сервере.
Как безопасно хранить ключи на устройстве?
Если ключ обязан быть на устройстве (например, токен после аутентификации) — используйте Android Keystore или Keychain Services. Нативное хранение в Keystore в 100 раз надежнее Shared Preferences.
Android:
val keyStore = KeyStore.getInstance("AndroidKeyStore") keyStore.load(null) val keyGen = KeyGenerator.getInstance(KeyProperties.KEY_ALGORITHM_AES, "AndroidKeyStore") keyGen.init( KeyGenParameterSpec.Builder("my_key_alias", KeyProperties.PURPOSE_ENCRYPT or KeyProperties.PURPOSE_DECRYPT) .setBlockModes(KeyProperties.BLOCK_MODE_GCM) .setEncryptionPaddings(KeyProperties.ENCRYPTION_PADDING_NONE) .build() ) // шифруем токен, сохраняем зашифрованный blob в EncryptedSharedPreferences EncryptedSharedPreferences из androidx.security:security-crypto — удобная обертка, автоматизирующая этот процесс.
iOS: Keychain Services через SecItemAdd/SecItemCopyMatching. В Swift используйте KeychainAccess или SwiftKeychainWrapper. Укажите атрибут kSecAttrAccessible = kSecAttrAccessibleWhenUnlockedThisDeviceOnly, чтобы данные не мигрировали с резервной копией iCloud.
Почему серверное хранение — единственный безопасный вариант?
API-ключи к внешним сервисам (платежные шлюзы, SMS-провайдеры, AI API) должны храниться на сервере. Клиент делает запрос к своему бэкенду, бэкенд — к Stripe/Twilio/OpenAI со своим ключом. Клиент никогда не получает этот ключ. Это в десятки раз безопаснее для критичных данных.
Паттерн для ключей с ограниченным доступом: клиент аутентифицируется, сервер выдает короткоживущий токен (JWT или HMAC-подписанный nonce) с конкретными permissions. Например, для загрузки файлов напрямую в S3 используйте presigned URL — основной ключ не покидает сервер.
Когда оправданы NDK и обфускация?
Если строка должна быть в приложении и нельзя запрашивать её с сервера — применяйте нативный код. JNI функция возвращает ключ, собранный из нескольких частей:
JNIEXPORT jstring JNICALL Java_com_example_NativeKeys_getApiKey(JNIEnv *env, jobject obj) { const char part1[] = {0x41, 0x42, 0x43, 0x00}; const char part2[] = {0x44, 0x45, 0x46, 0x00}; // сборка + XOR расшифровка } Это security through obscurity, но порог атаки растет: нативный код сложнее хукать автоматическими инструментами.
Build-time защита: как не допустить утечки в репозитории
Используйте local.properties (игнорируется git) для переменных сборки. Пример:
MAPS_API_KEY=AIzaSy... В build.gradle:
manifestPlaceholders = [mapsApiKey: properties["MAPS_API_KEY"] ?: ""] В AndroidManifest:
<meta-data android:name="com.google.android.geo.API_KEY" android:value="${mapsApiKey}"/> Ключ не попадает в репозиторий, но попадает в APK — всё равно читается из манифеста. Для Maps Key это приемлемо с ограничениями по package name и SHA-1, но не для настоящих секретов.
Сравнение методов защиты
| Метод | Уровень безопасности | Сложность реализации | Рекомендация |
|---|---|---|---|
| Хранение в коде (строка/ресурс) | Низкий | Низкая | Никогда не использовать |
| Обфускация (ProGuard/R8) | Низкий-Средний | Средняя | Недостаточно для секретов |
| NDK + шифрование | Средний | Высокая | Для ключей, которые невозможно вынести |
| Keychain/Keystore | Высокий | Средняя | Для токенов и данных после аутентификации |
| Серверный прокси | Очень высокий | Средняя | Для всех внешних API-ключей |
Типичные ошибки при защите ключей
- Хранение ключей в
BuildConfigили ресурсах — первый признак утечки. - Использование одинаковых ключей для dev и production — рискуете на этапе разработки.
- Отсутствие ограничений в консолях провайдеров — Maps Key без рестрикции украдет любой.
- Пренебрежение ротацией ключей — периодически меняйте ключи, особенно при подозрении на утечку.
Что входит в нашу работу
- Аудит всех API-ключей и секретов в коде, конфигурациях и билд-скриптах.
- Миграция критичных ключей на сервер с настройкой прокси-сервиса.
- Внедрение Keychain/Keystore для токенов и клиентских секретов.
- Настройка ограничений в Google Cloud Console, Stripe, Firebase и других сервисах.
- Документация с описанием новой схемы хранения.
- Post-launch поддержка — месяц бесплатных консультаций.
Процесс работы: от аудита до деплоя
- Анализ — ищем все места, где используются ключи.
- Проектирование — решаем, какие ключи выносим на сервер, какие оставляем на устройстве.
- Реализация — пишем код для Keychain/Keystore, прокси-сервера, обновляем билд-процесс.
- Тестирование — проверяем, что ключи не утекают даже при анализе трафика или декомпиляции.
- Деплой и мониторинг — публикуем обновление, настраиваем алерты на необычную активность.
Полная реализация схемы защиты занимает от 2 до 5 дней в зависимости от количества ключей и архитектуры. Стоимость рассчитывается индивидуально после аудита. Мы защитили более 20 мобильных проектов. Свяжитесь с нами для бесплатной оценки вашего проекта. Получите консультацию — напишите нам.