Hard-coded API keys are easy to find in an app package. Anyone who inspects the package can read a key stored in plain code or resources. A leaked key can allow abuse of a paid service. It can also expose user data when the key grants broad access. This guide explains safer ways to handle credentials in mobile apps.
Start by listing every key and secret in your app. Include keys in code and keys in build files and keys in resource files. Note which service each key accesses and what damage a leak would cause. A key with broad access needs stronger protection than a key for a public map tile service. This inventory guides all later decisions.
Remove hard-coded keys from the main code path as a first step. Move sensitive calls to a server that you control when possible. A server can hold the real key and the app can request data through the server. This design keeps the key out of the shipped package. It also lets you rotate a key without shipping a new app version.
Move Sensitive Calls To A Server
A server proxy is the safest pattern for sensitive API calls. The app sends a user request to your server. Your server adds the real key and calls the third party service. The service returns data to your server and your server returns a safe result to the app. The key never leaves the server in this flow.
Design the server endpoint to limit what a caller can request. Check user authentication before you call the third party service. Apply rate limits to prevent abuse from a single account. Log usage patterns so you can spot a leaked user token early. A limited server endpoint is safer than a direct key in the app even when the server code is simple.
- Inventory every key and secret in the app
- Move sensitive calls behind your own server
- Limit server endpoints by user and rate
- Rotate keys on a regular schedule
- Monitor usage for unusual patterns
Use Restricted Keys When A Client Key Is Unavoidable
Some services need a key in the client app. A map service or a public data service may require a client key. Restrict that key by package name and by certificate fingerprint when the service supports it. Set usage quotas that match normal app traffic. A restricted key limits damage when it leaks because it works only from your app and within a quota.
Separate keys by environment. Use a test key for development and a production key for release. A test key leak should not affect production data. Rotate the production key when a team member leaves or when a leak is suspected. A rotation plan should be written before a leak happens so the team can act quickly.
Restricted keys also relate to signature work in the material on app signature verification. A restriction tied to a signing certificate depends on that certificate staying private. Protect your signing key with the same care as any other secret. A leaked signing key can weaken several protections at once.
Store Tokens Securely On Device
User tokens need secure storage on the device. Use the platform keystore for sensitive tokens when the platform provides it. The keystore ties stored data to device hardware in many cases. Avoid storing tokens in plain shared preferences. Avoid storing tokens in plain files that other apps could read.
Expire tokens after a reasonable time and refresh them through a secure flow. A short-lived token limits damage when it leaks. A refresh flow should require proof of the original login. Test token expiry by waiting for expiry in a test build or by forcing expiry in a debug setting. A clear expiry behaviour prevents stale sessions from lingering.
Remove Secrets From Build Files And Logs
Build files can leak secrets when they are committed to a shared repository. Check build scripts and configuration files for keys before you share code. Use environment variables on a build machine for secrets that the build needs. Keep those variables out of logs and out of shared build output. A build log that prints a key defeats all other protections.
Search logs for secret patterns during testing. A debug log can print a full request including a token. Remove secret values from logs before release. Use placeholders in logs when you need to confirm that a request included a token. A placeholder proves presence without exposing the value.
Rotate And Revoke Keys Quickly
Rotation means replacing an old key with a new key on a schedule. Revocation means disabling an old key immediately after a suspected leak. Both actions need a plan that the team can follow under pressure. Store the new key in the server or in the restricted key service. Update the app only when a client key must change.
Test rotation in a staging environment before you rotate production keys. A staging test reveals code that depends on the old key. Fix those dependencies before the production rotation. After rotation monitor error rates for a short period. A spike in errors may mean a missed dependency that needs a quick fix.
Audit Packages For Leaked Secrets
Audit your own package before release with a secret scan. Search the package for key patterns and for known service names. Search decompiled code and resources and native libraries. A scan can find a key that a developer added by accident. Fix any finding before release and rotate the key if it ever shipped in a public build.
Repeat the audit after every major release. New libraries can add keys or change storage patterns. A regular audit catches leaks early when rotation is still cheap. Add the audit to your release checklist so it never depends on memory. A checklist item turns a good practice into a reliable habit.
api_key = load_from_secure_store()
if api_key is None:
show_error()The snippet above is an original example written for this guide. It shows generic logic that you can adapt to your own project. It does not copy code from any outside source.
The snippet shows a safe pattern where a missing key triggers an error rather than a fallback to a plain value. Use this pattern in code that needs a credential. Never add a plain fallback key for convenience.
Teach Credential Safety To The Team
Credential safety fails when only one developer understands it. A teammate who does not know the rule may add a hard-coded key to fix a quick bug. Teach the team the basic rules in a short session. A session should cover server storage and restricted keys and secure device storage and rotation. Use real examples from the project so the rules feel concrete. A team that shares the same rules makes fewer mistakes.
Add credential checks to code review. A reviewer should search new code for key patterns and for plain token storage. A review checklist item for credentials makes the check routine. A routine check catches a key before it reaches a release build. A key caught in review costs minutes to fix. A key caught after release costs a rotation and a security review.
Run a credential audit after onboarding a new team member. A new member may bring habits from a previous project where hard-coded keys were normal. An audit after onboarding catches those habits early. Pair the audit with a friendly explanation of the project rules. Education plus audit builds a culture where credential safety is normal work and not an extra burden.
Credential education should also cover third party services that the app uses. A service may require a key for a map or for analytics. Each service key needs the same restriction and rotation discipline as an internal key. List third party keys in the same inventory as internal keys. A complete inventory prevents a forgotten service key from becoming a leak.
Review third party key settings after each service update. An update can change restriction options or quota settings. A setting that once limited a key may reset to a broad default after an update. A post-update check catches that reset early. Add the check to the release checklist for any release that updates a service library.
Common Mistakes
A common mistake is hiding a key with simple encoding and calling it secure. Encoding is not encryption and it is easy to reverse. Use server storage or restricted keys instead of encoding tricks. An encoded key in a package is still a leaked key.
Another mistake is committing keys to a shared repository. A repository history can preserve a key even after you delete it from current code. Rotate any key that ever entered a shared repository. Treat repository history as public even for a private project.
Some developers also log tokens during debugging and forget to remove the logs. Debug logs can ship in a release build by accident. Search release logs for token patterns before you ship. A log audit is a short step that prevents a serious leak.
Finally do not use one key for every service and environment. A single key leak can affect many services at once. Separate keys by service and by environment. Separation limits damage and makes rotation simpler.
Frequently Asked Questions
Can I store any key safely in an app?
No client app can fully hide a key from inspection. Use server storage for sensitive keys. Use restricted keys only for services that require a client key.
What should I do if a key leaks?
Revoke the leaked key immediately and issue a new key. Check usage logs for abuse during the leak window. Update server code and restricted key settings before you ship a fix.
Does obfuscation protect a key?
Obfuscation raises the effort needed to find a key but it does not make the key safe. Treat an obfuscated key as still visible to a determined inspector. Use server storage for real protection.
Conclusion
Secure credentials need server storage and restricted keys and safe device storage. Inventory every secret and move sensitive calls behind your own server. Rotate keys on a schedule and audit packages before release. Your concrete next step is to inventory the keys in your app today and move the most sensitive call behind a server endpoint. Test the new flow and then rotate any key that ever shipped in plain code. For related work you can study custom licensing and authentication and proxy traffic inspection and manifest permissions and Play rejections as next steps.
