A mobile app security checklist before you ship

Most mobile security problems are avoidable with a short, consistent check before release. This is a practical checklist you can run on every Android and iOS build, in plain terms, with no assumptions about which tools you use.

The goal is not to be exhaustive. It is to catch the issues that cause real incidents, every time you ship, instead of once a year.

The pre-release checklist

• No secrets in the package. Scan the build for keys, passwords and tokens. Move anything privileged to a backend and rotate anything that leaked.
• Sensitive data is protected on the device. Use the platform keystore or keychain, not plain files, and do not log sensitive values.
• All traffic uses TLS with working certificate checks. No cleartext, no disabled validation, and pinning enforced where your risk level needs it.
• Exported components and debug flags are off in production. Only expose what other apps genuinely need to reach.
• Every bundled SDK is known and current. Keep an inventory, check it against known vulnerabilities, and drop the libraries you do not use.
• The app behaves on a rooted or jailbroken device the way your risk level requires, including tamper and repackaging resistance for apps that handle money or identity.
• Findings are tracked and fixed, not just listed. Give each one an owner, a severity and a due date.

How to run it

Run the fast items on every release. Static analysis and secret scanning are cheap enough to live in the build pipeline, so they ride your existing release train and can fail the build when a new critical appears. Save the deeper, slower work, dynamic and runtime testing, for important builds.

The point is consistency. Mobile code changes fast and so do the SDKs inside it, so a check that runs every release catches regressions a yearly audit never sees.

Common mistakes to avoid

Four mistakes account for most of the trouble. Treating a mobile app like a thin wrapper around a website, which ignores everything that lives on the device. Testing once a year, which misses the build you actually shipped. Ignoring third-party SDKs, which is where a lot of real exposure hides. And listing findings without fixing them, which turns a report into shelfware.

Avoid those four and the checklist above does the rest. For the bigger picture, read what is mobile application security.

Common questions