Every Android and iOS build you publish can be downloaded, unpacked and read. Most of the mobile security issues that reach users are not clever attacks. They are a debug setting left on, an API secret compiled into the app, a login token in a plain file or a log line that prints the OTP. A short checklist run before every release catches most of them.
This post gives you that checklist, grouped by area and mapped to the OWASP Mobile Application Security Verification Standard (MASVS). It complements a full test rather than replacing it; for what a complete assessment covers, see our mobile app security testing guide.
Quick answer: Before each release, confirm it is a signed release build with debugging off, no secrets or test URLs in the code, tokens stored with the Android Keystore or iOS Keychain, HTTPS-only traffic, only the permissions you need, safe deep links and exported components, and no sensitive data in logs. Then confirm the backend enforces every permission check itself.
Build and configuration checks
These settings decide how easy your app is to inspect and misuse. Check them on the actual release build, not on the project defaults.
Android
- Debugging off: the release build must not set android:debuggable to true, and the signing key must be stored outside the code repository.
- Code shrinking on: enable R8 minification and obfuscation. It slows down reverse engineering, but it does not hide secrets.
- Backups reviewed: decide whether android:allowBackup should be off, or use backup rules to exclude tokens and local databases.
- Exported components: set android:exported deliberately on every activity, service and receiver. Apps targeting Android 12 or later must declare it for components with intent filters.
- No cleartext traffic: keep the network security configuration HTTPS-only and do not trust user-installed certificates in release builds.
iOS
- App Transport Security: remove broad exceptions such as NSAllowsArbitraryLoads from Info.plist, or document why a narrow exception is needed.
- Debug features removed: hidden menus, environment switchers and verbose logging should not ship in App Store builds.
- URL schemes and universal links: confirm every link the app accepts validates its input and cannot trigger a payment or account change on its own.
Data storage and logs
Assume that a lost, shared or rooted phone will be examined. Anything the app writes to the device should be either harmless or protected.
- Tokens and keys: store them in the iOS Keychain, or encrypt them with a key held in the Android Keystore. Plain SharedPreferences and UserDefaults are not suitable.
- Local databases: keep only what the app needs offline. Encrypt local databases that hold personal or financial data.
- Logs: release builds should never log tokens, OTPs, passwords, PAN or Aadhaar numbers. Check device logs while you use the release build.
- Screens and clipboard: on Android, FLAG_SECURE blocks screenshots of sensitive screens; on iOS, hide sensitive content when the app moves to the background. Avoid copying OTPs or account numbers to the clipboard.
Secrets and endpoints a decompiler will find
Tools such as jadx and apktool turn an APK back into readable code in minutes, and iOS apps can be inspected too. Treat everything in the app package as public.
- Payment gateway keys: a Razorpay key ID is meant to be used in the app, but the key secret must stay on your server. The same idea applies to other gateways.
- Cloud and SMS credentials: AWS access keys, SMS or email API keys and admin tokens should never be in the app. Route those calls through your backend.
- Firebase: the API key in the config file is not a secret, so your Firestore, Realtime Database and Storage security rules must be what restricts access.
- Leftovers: remove staging and UAT base URLs, test accounts and commented-out admin endpoints.
- Third-party SDKs: review each SDK, its version and the data it collects. Google Play's Data safety section and Apple's privacy details both ask you to declare this accurately.
Network, login and the backend
Many serious mobile issues sit behind the app, in the APIs it calls. The app can make attacks harder; only the server can actually stop them.
- Certificate pinning: if you pin, ship a backup pin and a rotation plan, or a certificate change can lock every user out.
- Sessions: use short-lived access tokens, rotate refresh tokens and make logout invalidate the session on the server.
- Biometric login: it should release a credential held in the Keystore or Keychain, not just return true or false inside the app.
- Root and jailbreak detection: treat it as a speed bump. Your server must never trust a value just because the app sent it.
- Server-side checks: every API must check that the logged-in user owns the record requested, and OTP and login endpoints need rate limits.
The checklist mapped to OWASP MASVS
MASVS groups mobile security controls into areas. Use this table as a release gate, and see the OWASP MASVS for the full set of controls.
| MASVS area | Check before release |
|---|---|
| MASVS-STORAGE | No tokens or personal data in plain files, logs, backups or caches |
| MASVS-CRYPTO | Keys held in Keystore or Keychain; no hard-coded keys or home-made encryption |
| MASVS-AUTH | Sessions expire and are revoked on the server; biometrics tied to stored credentials |
| MASVS-NETWORK | HTTPS only, no user CA trust in release, pinning with a backup plan if used |
| MASVS-PLATFORM | Exported components, deep links, WebViews and permissions reviewed |
| MASVS-CODE | Release build, dependencies and SDKs up to date, minimum app version enforced |
| MASVS-RESILIENCE | Obfuscation on, tamper and root checks where your risk needs them |
| MASVS-PRIVACY | Only necessary data collected, store declarations match what SDKs actually do |
When a checklist is not enough
A checklist confirms you avoided known mistakes. It does not show how an attacker would chain smaller weaknesses together, or whether your backend leaks other users' data. Plan a full test when:
- you are releasing the first public version of an app that handles payments, KYC or health data;
- you change login, payments or how the app talks to the backend;
- an enterprise customer, bank or partner asks for an independent security report;
- the app has not been tested for a year or after several major releases.
How EthicsComputer can help
Our mobile app security testing combines static analysis of the APK or IPA, dynamic testing on rooted and jailbroken devices and manual testing of the APIs the app calls, with findings mapped to MASVS. Most assessments typically take 5 to 15 working days, and you also receive a release security checklist for future builds. If the app is still being built, our mobile app development team can build these checks in from the start.
Is your next app release ready for a security check?
Share your platforms, release date and what the app does with user data, and we will suggest a test scope that fits your timeline.
About the author
Vinay Grover founded EthicsComputer in Rohtak, Haryana in 2018 and leads its cybersecurity, software and AI work for clients across India and abroad. EthicsComputer is ISO 9001, ISO/IEC 27001 and ISO 20000-1 certified.
