strings app.apk | grep -i "key\|secret\|token" — in most unprotected apps, this command leaks several secrets. Google Maps API Key in AndroidManifest.xml, Firebase API Key in google-services.json, Stripe Publishable Key in source code — all of these can be extracted from an APK without reverse engineering. We've encountered projects where keys were hardcoded, visible to anyone who downloaded the app.
Why you can't store keys in code
Any key embedded in resources or constants is public. APK and IPA files are decompilable; obfuscation only makes extraction harder but doesn't prevent it. For example, a key in local.properties still ends up in the build and can be read from the manifest. Google Maps API Key can be restricted by package name and SHA-1, but for real secrets (like a payment gateway key) that's not a solution.
You often hear: "Firebase API Key is public, it's fine to expose it." Technically true for apiKey — it identifies the project, access is controlled by Firebase Rules. But Maps Key, Stripe Secret Key, backend keys are different. A leaked Maps Key can result in unauthorized requests billed to you. We guarantee that after our work, keys will never leave the device unnecessarily, and server secrets stay on the server.
How to securely store keys on the device
If a key must be on the device (e.g., a token after authentication), use Android Keystore or Keychain Services. Native storage in Keystore is 100 times more reliable than 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() ) // encrypt token, store encrypted blob in EncryptedSharedPreferences EncryptedSharedPreferences from androidx.security:security-crypto is a convenient wrapper that automates this process.
iOS: Keychain Services via SecItemAdd/SecItemCopyMatching. In Swift, use KeychainAccess or SwiftKeychainWrapper. Set the attribute kSecAttrAccessible = kSecAttrAccessibleWhenUnlockedThisDeviceOnly to prevent data migration with iCloud backups.
Why server-side storage is the only secure option
API keys for external services (payment gateways, SMS providers, AI APIs) must be stored on the server. The client makes a request to your backend, and your backend makes the request to Stripe/Twilio/OpenAI using its own key. The client never receives that key. This is dozens of times safer for sensitive data.
Pattern for keys with limited access: the client authenticates, the server issues a short-lived token (JWT or HMAC-signed nonce) with specific permissions. For example, for direct file uploads to S3, use presigned URLs — the master key never leaves the server.
When NDK and obfuscation are justified
If a string must be in the app and cannot be fetched from the server, use native code. A JNI function returns the key assembled from multiple parts:
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}; // assembly + XOR decryption } This is security through obscurity, but it raises the attack bar: native code is harder to hook with automated tools.
Build-time protection: preventing leaks in repositories
Use local.properties (ignored by git) for build variables. Example:
MAPS_API_KEY=AIzaSy... In build.gradle:
manifestPlaceholders = [mapsApiKey: properties["MAPS_API_KEY"] ?: ""] In AndroidManifest:
<meta-data android:name="com.google.android.geo.API_KEY" android:value="${mapsApiKey}"/> The key doesn’t end up in the repository, but it still ends up in the APK and can be read from the manifest. For Maps Key this is acceptable when combined with package name and SHA-1 restrictions, but not for real secrets.
Comparison of protection methods
| Method | Security Level | Implementation Complexity | Recommendation |
|---|---|---|---|
| Storing in code (string/resource) | Low | Low | Never use |
| Obfuscation (ProGuard/R8) | Low–Medium | Medium | Not enough for secrets |
| NDK + encryption | Medium | High | For keys that cannot be moved |
| Keychain/Keystore | High | Medium | For tokens and data after authentication |
| Server proxy | Very high | Medium | For all external API keys |
Common mistakes when protecting keys
- Storing keys in
BuildConfigor resources — first sign of leakage. - Using the same keys for dev and production — risk during development.
- Missing restrictions in provider consoles — Maps Key without restriction can be stolen by anyone.
- Neglecting key rotation — periodically change keys, especially if a leak is suspected.
What our work includes
- Audit of all API keys and secrets in code, configurations, and build scripts.
- Migration of critical keys to a server with a proxy service setup.
- Implementation of Keychain/Keystore for tokens and client-side secrets.
- Configuration of restrictions in Google Cloud Console, Stripe, Firebase, and other services.
- Documentation describing the new storage scheme.
- Post-launch support — one month of free consultations.
Work process: from audit to deployment
- Analysis — find all places where keys are used.
- Design — decide which keys move to server, which stay on device.
- Implementation — write code for Keychain/Keystore, proxy server, update build process.
- Testing — verify keys don't leak even under traffic analysis or decompilation.
- Deployment and monitoring — publish update, set up alerts for unusual activity.
A full protection scheme takes 2 to 5 days depending on the number of keys and architecture. Cost is calculated individually after an audit. We have secured over 20 mobile projects. Contact us for a free assessment of your project. Get a consultation — write to us.