Mobile app security: the checklist before you ship
Most mobile breaches are not clever. They are secrets in the binary, trust placed in the client, and data stored where anyone with the device can read it.
Key takeaways
- Treat any key compiled into the app as public; privileged actions belong behind a server endpoint.
- Every authorisation decision happens server-side; hiding a button is usability, not security.
- Store tokens in the platform keychain or keystore, and check that no log statement prints credentials.
- Audit every third-party SDK; they run with your permissions and cause most privacy declaration mismatches.
Mobile security failures are overwhelmingly mundane: API keys embedded in the app, authorisation decided on the client, sensitive data written to unprotected storage, and traffic that can be intercepted. A short pre-launch review covering those four categories eliminates most of the realistic risk, and none of it requires specialist tooling.
Nothing secret ships in the binary
An app is downloadable by anyone and can be decompiled. Any key, password or token compiled into it should be treated as public. Obfuscation delays this and does not prevent it. Anything that must remain secret belongs on your server, with the app calling an endpoint that performs the privileged action rather than holding the credential to perform it itself.
The server decides, always
- Every authorisation check happens server-side. Hiding a button in the interface is a usability choice, not a security control, and the underlying request can still be made.
- Validate all input server-side regardless of client validation. The client can be replaced entirely.
- Never trust identifiers supplied by the client for access decisions. If the request says give me order 4471, verify that this authenticated user owns it.
- Rate limit authentication endpoints. Credential stuffing against a mobile API is trivial without it.
Storage and transport
Tokens and credentials belong in the platform keychain or keystore, not in preferences, not in a plain local database, and never in logs. Be specific about logging: a debug statement printing an authorisation header is one of the most common ways credentials leak, and it survives to production more often than teams expect.
All traffic over TLS, with no exceptions permitted for development convenience that then ship. Check that any transport security exemption added during development has been removed before release.
Third-party code is your risk
Every SDK you include runs with your app's permissions and can read what your app reads. Audit what each one collects and transmits, remove any you are not actively using, and keep the rest updated. This is also where privacy declaration mismatches originate, since an advertising or analytics library may collect identifiers you never declared.
Before submission
Remove debug endpoints and test accounts. Confirm the production build points at production infrastructure. Verify the privacy declarations match what the app and every SDK actually do. And make sure you can revoke a compromised token without shipping an update, because at some point you will need to.
Session and token handling
Use short-lived access tokens with refresh rather than a long-lived credential stored on the device, so a stolen token expires by itself. Make sure sign-out actually revokes server-side rather than only clearing local storage, since a token that remains valid after the user signed out is a real exposure on a shared or lost device.
Handle the account recovery path with the same care as the login path. It is frequently the weakest link, because it is built once, tested lightly, and grants full access by design. A recovery flow that reveals whether an email address is registered also hands an attacker a way to enumerate your users.
Deciding what actually needs protecting
Spend the security budget in proportion to consequence. An app holding payment instruments, identity documents or health information warrants a formal review and probably a penetration test. An internal tool showing a delivery schedule does not, and treating both identically means either overspending on one or under-protecting the other. Write down what the worst realistic outcome of a breach would be, and let that decide the depth of the work.
Anything compiled into the app is public. Obfuscation delays discovery; it does not prevent it.
Sources