Handle secrets in Kotlin by keeping them out of source control, assuming anything compiled into an Android app can be extracted, using the Android Keystore for keys created on the device, scoping every API key tightly, and moving high value credentials to a backend you control.
What does Android say about keys in an app?
The Android developer guidance on API key management says that when an app is compiled with API keys in its source, an attacker can decompile the app and find them. It warns that exposure can lead to data breaches, unauthorised access and financial losses.
That sentence changes how you think about the problem. A secret inside a client is not secret. It is a key with a long delay before it leaks. So the question for each key is how much damage it can do when found, and whether it should be in the client at all.
A constructed example: a delivery app embeds a mapping service key with no restrictions. Someone extracts it from the APK and uses it in their own product, and the monthly bill arrives with your name on it. If the key were restricted to your app's package and signing certificate, the stolen copy would be useless elsewhere.
What practices does the guidance list?
The Android documentation recommends, in its own words and order:
- Strong key storage: use the Android Keystore and encrypt stored keys with a tool such as Tink.
- Source control exclusion: never commit API keys. It suggests Gradle plugins such as the secrets Gradle plugin to supply values at build time.
- Environment specific keys: separate keys for development, testing and production, so that a compromised key can be disabled without affecting production.
- Unique keys per app, so compromised access can be isolated.
- IP restrictions where possible, and limiting use to specific mobile apps by bundling the key with the app or using app certificates.
- Logging and monitoring for misuse, and regular audits of the code for credential request issues.
Note that the secrets plugin keeps a key out of Git. It does not keep it out of the shipped app. Use both ideas together: keep out of the repository, and restrict the key as if it were public.
What is the Keystore for?
The Android Keystore system stores cryptographic keys in a container that makes them harder to extract. Once keys are in the keystore, you can use them for cryptographic operations while the key material stays non exportable. It also lets you restrict when and how keys are used, for example requiring user authentication or limiting a key to certain cryptographic modes. Key material can be bound to secure hardware such as a Trusted Execution Environment or a Secure Element, and then it is never exposed outside that hardware.
The Keystore protects keys the app creates, like the one that encrypts a local token cache. It does not give you a safe place to hide a third party API key that you shipped yourself.
What about Kotlin on the server?
On a Kotlin backend the rules are the usual ones: inject secrets at runtime from a secrets manager or the platform's secret mechanism, never from a file in the repository, never into logs, and rotate on a schedule and after any exposure. Move any call that needs a high value key behind your own API, so the mobile app authenticates the user and your backend holds the third party credential.
How to check or apply this
- Run a secret scanner over the repository and its history, and rotate anything found.
- List every key inside the app and mark what happens if it is stolen.
- Restrict each key by app, certificate and API, and use separate keys per environment.
- Move any key that can spend money or read user data to the backend.
- Store locally created keys in the Android Keystore, and encrypt other stored secrets with a maintained library.
- Set budget alerts and usage monitoring on third party APIs.
- Put scanning in CI so a committed key is caught on the pull request.
Try it yourself
Open the full demo.
Quick check
Does the secrets Gradle plugin make a key safe?
No. It keeps the key out of version control. The key still ends up in the built app, so restrict it as if public.
Is the Keystore a vault for third party API keys?
No. It protects key material that the app generates or imports for cryptographic operations. A third party key should live on your backend.
Sources
Last reviewed: 18 October 2026.
