Mobile App Security and User Data

The device is not trusted

The central difference from web security is that your code is running on hardware you do not control, in the hands of someone who may be curious or hostile. An app can be decompiled, its network traffic inspected, its local storage read on a rooted device.

Everything else follows from accepting that: nothing secret goes in the app, and nothing the app claims is verified without checking it on the server.

An API key compiled into a mobile app is a public API key. It has simply not been published yet.

The mobile-specific mistakes

1. Secrets in the binary. API keys, credentials, encryption keys. Extractable in minutes.
2. Sensitive data in plain local storage. Tokens and personal data belong in the platform keychain, not in preferences.
3. Trusting the client. Prices, permissions, discounts and eligibility validated in the app and not re-checked on the server.
4. Over-collecting. Requesting location, contacts and photos because a library wanted them, which triggers store scrutiny and user distrust.
5. Logging sensitive values. Debug logging left on, writing tokens to the device log.

Storing things correctly

• Auth tokens in the platform secure storage — Keychain on iOS, Keystore on Android
• Short-lived access tokens with refresh, so a stolen token expires
• Nothing sensitive in plain local databases; encrypt if it must be held
• Biometric unlock for high-value actions, backed by a real check
• A remote logout that actually invalidates the token server-side

The network

HTTPS everywhere, obviously. Beyond that, certificate pinning is worth considering for apps handling money or health data, with the caveat that it complicates certificate rotation and has caused more than one outage.

Our default is pinning for financial and health apps, standard TLS for everything else, and a remote configuration switch either way so a certificate problem does not require a store release to fix.

Permissions and disclosure

Request permissions at the moment of use with an in-context explanation, and only the ones you genuinely need. Both stores require accurate declarations of what you collect, and both check them.

• Inventory every SDK and what it sends — analytics libraries collect more than teams expect
• Match the store declaration to observed behaviour exactly
• Provide a data deletion route; both stores now expect one
• Keep the privacy policy current when the app changes

What to do about a compromised release

Have the mechanism before you need it: the ability to force an update, revoke tokens, and disable a feature remotely. All three are cheap to build in advance and impossible to add to copies already installed.

Then decide the process: who is called, who can force the update, who talks to users. An app incident is slower to fix than a web one because of review, which makes the plan more valuable rather than less.

Frequently asked questions