Mobile App Security Checklist
By CodexierPublished 5 min read
A mobile app runs on hardware you do not own, on networks you do not trust, next to apps you did not choose. That changes what security means compared with a website: the device can be lost, the app can be decompiled, and the network can be a café. This checklist follows the structure of the OWASP mobile guidance and focuses on what a business app for staff or customers actually needs, not on what a banking app needs.
Secure storage on the device
- Session tokens in the iOS Keychain or Android Keystore, with a short lifetime and a refresh flow, never in a plain file or the app's preferences.
- Cached business data encrypted at rest if it is personal or commercial, and wiped on logout and after a period offline.
- No sensitive data in logs, crash reports or screenshots. Mask the app in the task switcher on screens that show personal data.
- Remote wipe or forced re-login when a device is reported lost; the server invalidates the session, not the app.
Transport security
All traffic goes over HTTPS with current TLS versions, and the app refuses to fall back. Both platforms enforce this by default now; the risk is a developer switching it off to test against a local server and shipping it that way.
- No cleartext exceptions in the release build configuration. Check the Android network security config and iOS transport settings before each release.
- Certificate pinning only for high-value apps and only with a rotation plan; a pinned certificate that expires bricks the app for every user.
- Third-party SDKs (analytics, crash reporting, ads) send data too. List them, read what they collect and remove the ones you cannot justify to a customer.
Secrets and configuration
Assume the binary is public
Anyone can download and decompile the app. An API key inside it is a published key. Server-to-server secrets never ship in the app at all.
Scope what must be client-side
Map keys, analytics keys and similar are restricted per platform and bundle id, rotated when leaked, and monitored for unusual use.
Separate environments
Development, staging and production have different API hosts and keys. A test build must not be able to reach production data.
Testing and dependency updates
Mobile apps decay faster than websites: operating systems change yearly, libraries publish security fixes monthly, and an app that is not rebuilt stops working or stops being safe. Security is a routine, not a launch task.
- Automated dependency scanning in the build pipeline, with a monthly update window and a rebuild even when nothing else changed.
- A short security test on each release: the two-account authorisation test, a check of release configuration, a look at what the app stores on a device.
- A yearly external review for apps handling personal or financial data, scoped to the API and the storage, not a full penetration test unless a customer requires it.
- Crash and error monitoring with personal data stripped, so a fault is seen before a user reports it.
This is the routine our app maintenance and scaling service runs monthly for apps we did not necessarily build. If you want a one-off check first, a health audit covers the same list once; both are fixed prices on the pricing page.
When this is more than you need
An internal app that shows a schedule and stores nothing personal needs the login, transport and update items and little else. A customer app handling payments, health data or identity needs all of it plus the platform's own requirements for those categories, and probably BankID. If your app was built by an agency that no longer answers, the first step is not this checklist but getting the source code and store accounts into your own hands, which a short call can help you plan.
Frequently asked questions
Is a cross-platform app less secure than a native one?
No. React Native, Flutter and Capacitor apps use the same platform keystores, the same TLS stack and the same store review. The security of an app is decided by how the API and storage are handled, not by the framework. Poorly written native apps are as common as poorly written cross-platform ones.
Do we need biometric login?
For a customer app that stays logged in, biometric unlock via the platform API is a cheap way to protect a lost phone and users expect it. For a staff app used on shared devices, a PIN with a short timeout may fit better. Either way the server session, not the biometric, is what gets revoked.
What do Apple and Google check in review?
Review checks privacy declarations, permissions, use of platform APIs and policy compliance. It does not test your API authorisation or your storage handling. Passing review means the app follows store rules, not that it is secure.
Not sure which items your app already passes?
Bring the app and a description of what it stores to a short call. We tell you which controls are urgent, which are fine to defer, and what a monthly maintenance routine covering them would cost.
Book a free 15-minute call