To reduce the exposure of secrets in a mobile app, first keep the high-value ones off the device: private keys, service credentials and signing secrets belong on your server, and the app should hold short-lived tokens instead. For the values that must ship, such as third-party API keys or configuration, Otukan encrypts them in the protected build, hides the code that uses them, and detects hooking and memory reading while they are in use on Android and iOS, including Flutter and React Native apps. Extraction becomes slow and visible, and a rotation and revocation plan limits what any leaked value is worth.
Secret classification
Start by sorting what your app carries. The right control depends on what the value can do in the wrong hands.
| Class | Examples | Harm if extracted | Where it belongs |
|---|---|---|---|
| Public identifiers | App bundle ID, package name, public client IDs, analytics project IDs | Low; they are meant to be visible | In the app, restricted on the server by app identity |
| Restricted API keys | Maps, push, search or content-service keys bound to your app | Quota abuse and cost if restrictions are weak | In the app with Otukan protection and server-side restrictions |
| Service credentials | Keys that call paid APIs or internal services with broad rights | Direct abuse of your services and data | On your server, behind a token exchange |
| Cryptographic secrets | Private keys, shared signing or encryption secrets | Forged requests, decrypted traffic or stored data | Generated in the platform key store, or kept server-side |
A key that lets anyone call your backend as if they were your app deserves the most attention. Classifying it correctly often shows it can move to the server.
Control placement
Server-side alternatives
The strongest option removes the secret from the app. Your backend can hold third-party credentials and act as a proxy for the calls that need them. The app can authenticate with short-lived tokens bound to the user and session. Your server can also verify app attestation before it issues those tokens, so only a genuine app on a genuine device receives one.
Justified client-side secrets
Some values must travel with the app: a key for an SDK that runs offline, a certificate pin, or configuration needed before sign-in. For these, Otukan:
- encrypts strings and marked resources in the protected build
- obfuscates the code that fetches, assembles and uses them
- detects hooking of key-handling functions and stops the call when your policy says so
- detects debuggers and memory-reading tools while secrets are in use
Platform key stores
Keys generated on the device should live in the platform store. On Android, the Keystore keeps key material out of the app’s process and can be hardware-backed on devices that support it. On iOS, the Keychain stores secrets under data protection classes, and on supported devices the Secure Enclave holds certain private keys for signing and key agreement. Each platform is handled on its own terms. Otukan protects the code that calls these stores, a natural target for hooking.
For a sector with high-value keys, see crypto wallet app security.
Operational lifecycle
Rotation
Plan for every embedded secret to change. Protection is applied within your existing build pipeline, so a rotated key ships in the next protected release like any other change. Keep old and new keys valid on the server during the overlap, then retire the old one.
Revocation
Revocation happens on your server, which is why server-side restrictions matter even for protected keys. Tie each key to an app identity and a scope so that revoking it is a clean, contained action.
Compromise response
When a secret leaks, revoke it, ship its replacement and watch uptake by app version. Otukan’s signals record which versions and flows were targeted, so you can judge whether to force older versions to update. Before release, we test with your team: attempt extraction in an authorised lab and confirm the signal, repeat the journey on a clean device and confirm silence, then re-run install, update, sign-in and the flow that uses the key.
Return to mobile app security for how secrets protection fits the wider product. For a structured way to evaluate options, see the secrets and key protection solution guide. If your app is already published, you can request a free App Exposure Check of the public store release.