No. Any secret that ships inside a mobile app can be pulled out by whoever installs it, because they hold the binary and the device. Obfuscation slows people down but does not change that. Keep real secrets on your server and give the app short-lived, narrowly scoped tokens instead.
Why an app cannot keep a secret
A mobile app is software you hand to strangers. Each copy can be unpacked, read, run in a debugger and watched on the network. Whatever the app needs at runtime, the person running it can see.
The OAuth standard for native apps says this directly. RFC 8252 states that secrets statically included in an app distributed to multiple users should not be treated as confidential, because one user may inspect their copy and learn the shared secret. The OWASP Mobile Application Security Cheat Sheet gives the same instruction in plain terms: do not hardcode credentials in the mobile app.
So the question is never how well you can hide the key. It is whether the key should be in the app at all.
Which values are safe to ship
Not everything in an app is a secret. The trick is to sort values by what happens if a stranger reads them.
| Value | Safe in the app? | Why |
|---|---|---|
| OAuth client ID for a public client | Yes | It identifies the app, it does not prove anything |
| Your own API base URL | Yes | Anyone watching traffic sees it anyway |
| Third-party secret or server key | No | It grants access in your name, with your billing |
| Signing key or admin credential | No | Full control, no per-user limit |
| Per-user access token, short lived | Yes, in secure storage | It is scoped to one user and expires |
If a value lets the holder spend money, read other users' data or act as your company, it belongs on a server.
Steps to take a key out of the app
- List every outbound call the app makes. Read the network layer and the third-party SDK configuration, not just your own API client.
- Mark each call that carries a secret. These are the ones to move.
- Add an endpoint on your own backend that makes the third-party call for the app. The backend holds the key and the app never sees it.
- Make the app sign users in with the authorization code flow and PKCE, then send the resulting access token to your backend. The backend decides what each user may ask for.
- Limit what the backend will do on a user's behalf: allowed operations, request size, and a per-user rate limit. A proxy with no limits is just a longer path to the same abuse.
- Rotate the old key. Every published version of the app that contained it is exposed, including old versions still installed on phones.
- Restrict the replacement key at the provider if it supports limits by IP address, referrer or scope, and set a spending cap.
What about obfuscation and encryption in the app?
Obfuscation makes extraction slower. Encrypting the key with another key stored in the app only moves the problem one step. Both are fine as extra friction for low value identifiers. Neither is protection for a credential that carries real authority.
The same logic applies to checks the app performs on itself. A tampered app can falsify its own results, which is why Apple's App Attest documentation tells developers they cannot rely on app logic to perform security checks on itself. Decisions belong on the server.
What to do if a key already shipped
Assume it is public. Rotate it, move calls behind the backend, ship the new build, then retire the old key once old versions have mostly aged out or been blocked by a minimum version check. Check the provider's usage logs for activity you do not recognise.
Safeguard's SBOM and dependency scanning covers the libraries inside your mobile builds, which helps you see which SDKs are making direct calls. You can try a free scan at gold.safeguard.sh/scan.
Quick check
Is a client config value or OAuth client ID a secret?
Identifiers meant to name your app are designed to be public, but check what each one can do on its own. If the identifier alone grants access to data or billing, protect it with server side rules or restrictions rather than hiding it.
Can I store the key in the Keychain or Android Keystore instead?
Those stores protect data on a device from other apps. They do not stop the device owner from getting the value after your app has fetched it, and they are for per-user secrets, not for a key shared by every install.
Do I need a backend just to call one third-party API?
If the call needs a secret, yes. A small proxy that authenticates the user and enforces limits is the usual answer.
Sources
- RFC 8252, OAuth 2.0 for Native Apps, section 8.5
- OWASP Mobile Application Security Cheat Sheet
- Apple, Establishing your app's integrity
Last reviewed: 19 October 2026.
