Mobile App Security Best Practices: An Android Developer Checklist
Good mobile app security is a set of small, checkable habits rather than one big feature. This checklist is organized around the OWASP Mobile Application Security Verification Standard (MASVS) and highlights the items you can verify straight from your APK's manifest.
- Follow the OWASP MASVS's eight areas: storage, crypto, auth, network, platform, code, resilience and privacy.[1]
- Keep keys in the Android Keystore[2], use TLS only[3], and never hard-code secrets.
- Export only the components you must, declare
android:exportedexplicitly[4], and validate every intent and deep link. - Verify the final release APK: debuggable off, backup intended, cleartext off, exported components expected.
The framework: OWASP MASVS
The OWASP MASVS groups mobile security requirements into eight areas: STORAGE, CRYPTO, AUTH, NETWORK, PLATFORM, CODE, RESILIENCE and PRIVACY.[1] The companion Mobile Application Security Testing Guide explains how to test each one.[6] The sections below translate them into Android actions.
Storage and cryptography
- Store as little as possible on the device. Data you never save cannot leak.
- Keep secrets in the Android Keystore, which is designed to prevent key material from being extracted from app processes and from the device, and which can use secure hardware (a StrongBox is available on devices running Android 9 or higher that include one).[2]
- Never hard-code keys, tokens or passwords in the app. Anyone can unpack an APK and read them.
- Use standard, vetted crypto libraries and current algorithms. Do not invent your own.
- Control backups. Set
android:allowBackup="false", or define explicit backup rules that exclude sensitive data, so private data is not silently included in device backups. - Do not log sensitive data, and clear it from the clipboard and screenshots where relevant.
Authentication
- Enforce authorization on the server. Anything the client decides can be changed by someone who controls the device.
- Use short-lived tokens and let them be revoked.
- Hash any local PIN or passcode with a slow, salted function; never store or compare it in plain text.
- Rate-limit and lock out guesses on every entry point, not just the main one.
- Use the platform biometric API for unlock, tied to a Keystore key where the data is sensitive.
Network communication
- Use TLS everywhere. Cleartext traffic has been disabled by default since Android 9 (API level 28); do not opt back in.[3]
- Never disable certificate validation or ship a TrustManager that accepts everything. Android's guidance on unsafe TrustManagers explains the danger.[5]
- Consider certificate pinning for high-risk apps, with backup pins and an expiration. See our guide to SSL pinning.
- Keep debug-only trust settings out of release builds.
Platform interaction: components, intents and WebViews
This is where the manifest matters most, because it declares what other apps on the device can reach. Android's general security tips cover the same ground.[7]
- Export only what must be exported. Set
android:exportedexplicitly; on Android 12 and higher an app with an undeclared value on a component that has intent filters cannot be installed.[4] Android's page on exported components explains the risk.[8] - Guard exported components with a permission where only specific callers should reach them.
- Validate every input from intents and deep links as untrusted. Verify App Links for web URLs.
- Make PendingIntents immutable unless you need them mutable.
- Harden WebViews. Disable JavaScript and file access unless needed, and restrict what the page can load.
- Request the fewest permissions, and only at the moment you need them.
Code quality and resilience
- Never ship a debuggable release.
android:debuggablemust be false. - Target a recent SDK level so you inherit newer platform protections.
- Update dependencies and scan them for known vulnerabilities.
- Enable code shrinking and obfuscation (R8) for release builds. It makes reverse engineering harder, though it is not a security boundary.
- Add integrity signals such as Play Integrity checks, evaluated on your server, as defense in depth. Our rooting guide explains their limits.
Privacy
- Collect only the data you need and say exactly what you collect.
- Keep your Play Data safety declarations accurate and in step with the code, including third-party SDKs.
- Be transparent about sensitive APIs. For example, if you use the accessibility service, explain why. See our accessibility guide.
- Give users a way to delete their data.
Verify the release build, not the source
Security settings can drift between source and shipped build, for example a debug flag that survives or a library that adds an exported component. Inspect the final APK. Upload it to the APK analyzer and confirm: debuggable is off, backup is intended, cleartext traffic is off, every exported component is expected, and pinning is configured if you rely on it. The steps for deeper inspection are in our APK analysis guide.
Frequently asked questions
What is OWASP MASVS?
The Mobile Application Security Verification Standard is an OWASP framework that lists security requirements for mobile apps across eight areas, from storage and cryptography to privacy and resilience.
Should I set allowBackup to false?
If your app stores anything sensitive, yes, or define explicit backup rules that exclude it. Leaving backup on by default can copy private app data into device backups.
Is code obfuscation enough to protect my app?
No. Obfuscation slows down reverse engineering but does not stop it. Real protection comes from keeping secrets and authorization on the server.
How do I check my app for exported components?
Inspect the final APK's manifest. Look for components with android:exported="true" and confirm each is intentional and, where appropriate, permission-guarded. App Checker's analyzer lists them for you.
What are the eight MASVS categories?
MASVS-STORAGE, MASVS-CRYPTO, MASVS-AUTH, MASVS-NETWORK, MASVS-PLATFORM, MASVS-CODE, MASVS-RESILIENCE and MASVS-PRIVACY. Each groups numbered security controls that an app can be verified against.
How do I store secrets securely on Android?
Use the Android Keystore for cryptographic keys, keep long-lived secrets on the server, and never embed API keys or passwords in the app, since anyone can unpack an APK to read them.
What is the OWASP MASTG?
The Mobile Application Security Testing Guide is OWASP's companion to the MASVS. It describes how to test each requirement, with techniques for both Android and iOS.
Should every app use certificate pinning?
No. It is most valuable for high-risk apps such as banking or health. Pinning needs backup pins and a rotation plan, and a mistake can lock users out, so weigh the risk for your app.
How often should I update dependencies?
Regularly, and immediately for known vulnerabilities. Outdated libraries are a common source of exposure, so scan your dependencies and rebuild whenever a security fix is released.
- OWASP Mobile Application Security Verification Standard (MASVS) — the eight control groups used to organize this checklist.
- Android Keystore system — Android Developers — preventing key extraction, secure hardware and StrongBox on Android 9+.
- Network security configuration — Android Developers — cleartext traffic disabled by default from API level 28.
- Behavior changes: Apps targeting Android 12 — Android Developers — explicit android:exported requirement for components with intent filters.
- Unsafe implementation of the TrustManager interface — Android Developers — why custom certificate validation is dangerous.
- OWASP Mobile Application Security Testing Guide (MASTG) — how to test each MASVS requirement.
- Security tips — Android Developers — general secure-coding guidance for Android.
- Android exported components risk — Android Developers — risks of exposing components to other apps.