Mobile App Security: A Practical Checklist

Short answer: mobile app security is mostly enforced on the server, not on the phone. The app bundle lives on the user's device, where it can be unpacked, inspected and modified. So the rule is simple: never trust the app, and validate every request on the server. The work on the phone itself is limited but critical: keep session tokens in secure storage, encrypt traffic, and ship no secrets in the bundle.

Why is mobile app security different from web security?

On a website, most of the code runs on your own server. A mobile app, by contrast, is a compiled package distributed to anyone through the App Store or Google Play. Opening an APK and reading its strings, API endpoints and any embedded keys takes minutes. Users also keep running old versions for months, so a vulnerability you fix today is not fixed for everyone today.

We covered the general server-side attack surface (SQL injection, brute force, outdated components) in our post on website security. This post focuses only on risks specific to mobile apps and on what to ask when you commission one.

Treat everything inside your app bundle as public. There is no such thing as a hidden key in a mobile app, only a key nobody has found yet.

The 6 most common mobile security mistakes

• Embedding the secret API key of a payment, SMS or maps service inside the app.
• Storing the session token in unencrypted storage (AsyncStorage, SharedPreferences).
• Enforcing permissions only in the UI: the button is hidden, but the API endpoint is open.
• Letting users reach someone else's record just by changing an ID (IDOR).
• Leaving verbose logs with phone numbers, emails or tokens in the production build.
• Shipping without a forced-update mechanism, so users cannot be moved to the version that fixes a flaw.

Four of these six are fixed on the server. That is why most mobile security work turns out to be API design; we explain the basics of the API side in what is API integration.

How should tokens and sensitive data be stored on the phone?

Session data belongs in the Keychain on iOS and in Keystore-backed encrypted storage on Android. Plain stores such as AsyncStorage can be read from a device backup or a rooted phone. React Native projects have mature libraries for this:

import * as Keychain from 'react-native-keychain';

// Wrong: plain text, readable from backups
// await AsyncStorage.setItem('refreshToken', token);

// Right: iOS Keychain / Android Keystore
export async function saveRefreshToken(token: string) {
  await Keychain.setGenericPassword('session', token, {
    accessible: Keychain.ACCESSIBLE.WHEN_UNLOCKED_THIS_DEVICE_ONLY,
  });
}

export async function readRefreshToken(): Promise<string | null> {
  const creds = await Keychain.getGenericPassword();
  return creds ? creds.password : null;
}

Access tokens should be short-lived (for example 15 minutes), and long-lived refresh tokens must be revocable on the server. When a user changes their password or loses their phone, you need to be able to end every session in one step. If you want to add a second factor at login, the rules in our post on SMS OTP verification apply to mobile just as well.

What needs to happen on the API side

• Identity and permissions are checked on the server for every request; every endpoint asks "may this user see this record?"
• Operations that need a secret key (payments, SMS, email) run on your server, not in the app; the app only calls your backend.
• Login, password reset and code-sending endpoints are rate limited.
• Responses return only the fields the screen needs, never the full user object.
• Play Integrity and App Attest are considered to confirm requests come from your genuine app, not a tampered copy.

Is certificate pinning necessary?

HTTPS is mandatory for every app. Certificate pinning goes further: the app only talks to servers presenting your certificate, which makes man-in-the-middle attacks much harder. It is recommended for banking, health and payment apps. The trade-off is that when you renew the certificate, older versions may stop connecting. Do not pin without a backup key and a planned renewal schedule.

Privacy law and store requirements

If the app collects personal data, you need a privacy notice, valid consent and a working way to honour deletion requests; in Turkey this falls under KVKK, in Europe under GDPR. Apple and Google also require you to declare in the store listing what data you collect and why, and a mismatch between that declaration and the app's behaviour can get it rejected. Our post on KVKK-compliant websites is a good starting point for mobile apps too.

Pre-release security checklist

• No secret keys, test accounts or internal server addresses left in the bundle.
• Tokens live in Keychain / Keystore, are short-lived and revocable.
• Requests made with another user's ID return 403.
• Debug logging is off in production, and personal data is masked in crash reports.
• Code shrinking and obfuscation (R8) are enabled on Android.
• Forced updates work, and the minimum supported version is controlled from the server.

Security is not a one-off task: dependencies need updating, OS changes need tracking, and every new feature should pass the same checks. You can see how this ongoing work affects the budget in our post on mobile app maintenance costs.

Conclusion

Mobile app security fits in three sentences: keep secrets out of the bundle, store tokens in secure storage, and validate every request on the server. Everything else is detail around those three rules. In our mobile app development projects, these checks are part of the design from day one. If you want a security review of your existing app or are planning a new one, get a quote and let's look at it together.