Mobile Secret Management

Build the mental model

A mobile app binary is not a private thing. It gets downloaded, installed, and stored on devices you do not control, potentially for years, across multiple versions, in the hands of anyone who cares to look closely.

An API key, a server credential, a signing secret for some third-party service -- none of it is actually secret once it ships inside an app binary, no matter how it is obfuscated or encoded. Obfuscation slows someone down; it does not stop them.

If a credential grants real privilege -- write access to a database, the ability to charge a payment method, admin rights on a third-party service -- it must never live inside the app itself.

The fix is architectural, not clever hiding: your backend holds the real secret credential, and the app talks only to your backend, which then talks to the third-party service on the server's behalf.

This matters more on mobile than the web, because a web deployment can be patched and redeployed in minutes, while an app binary already on millions of devices cannot be un-shipped -- only replaced by a future update those devices may not install for a long time, if ever.

BACKEND-PROXY PATTERN FOR MOBILE SECRETS
----------------------------------------
BACKEND-PROXY PATTERN FOR MOBILE SECRETS
-------------------------------------------
GOOD PATTERN
  Mobile App --> Your Backend (holds secret) --> 3rd-party API

BAD PATTERN (do not do this)
  Mobile App --> [Secret Bundled Directly] --> 3rd-party API
                     X inspectable in the shipped binary

Connect it to a real scenario

Do a pass over every configuration value baked into your app right now and sort each one into two piles.

• Fine to keep in the app: a base API URL, a publishable/restricted client key, an analytics id.
• Must never be in the app: anything that can write data, move money, or act with admin rights.

Watch for two sneaky versions of this mistake: a key that looks harmless today but becomes privileged later after a permission change in a dashboard, and a secret that sits in a config file or environment file that still ends up packaged into the shipped binary.

• A mobile app binary should be treated as inspectable -- obfuscation slows examination, it does not prevent it.
• Any credential granting real privilege must live on your backend, never bundled directly inside the app.
• This matters more than on the web: an installed app binary cannot be patched instantly the way a web deployment can.

Try the working example

function scanConfigForBundledSecrets(config) {
  const secretPattern = /secret|private[_-]?key|server[_-]?key/i;
  const safeMarkers = ["via-backend", "proxied"];
  const flagged = [];

  for (const [key, value] of Object.entries(config)) {
    if (safeMarkers.includes(value)) continue;
    const looksPrivileged = secretPattern.test(key);
    if (looksPrivileged) {
      flagged.push({ key, reason: "Looks like a privileged secret bundled directly in the app." });
    }
  }

  return { flaggedCount: flagged.length, flagged };
}

const riskyConfig = {
  STRIPE_SECRET_KEY: "sk_live_51H8xExampleNotReal",
  PAYMENT_SERVER_SECRET: "ex_srv_secret_998877",
  MAPS_API_KEY: "AIzaRestrictedPublicKeyExample"
};

const saferConfig = {
  STRIPE_SECRET_KEY: "via-backend",
  PAYMENT_SERVER_SECRET: "via-backend",
  MAPS_API_KEY: "AIzaRestrictedPublicKeyExample"
};

console.log("Risky config:", scanConfigForBundledSecrets(riskyConfig));
console.log("Safer config:", scanConfigForBundledSecrets(saferConfig));

The risky config flags 2 keys (STRIPE_SECRET_KEY, PAYMENT_SERVER_SECRET) as privileged secrets bundled directly, returning flaggedCount: 2. The safer config marks both as 'via-backend' and returns flaggedCount: 0.

OWASP Mobile Application Security (MASTG) — How Mobile Apps Work