Android gives developers a strong security foundation: app sandboxing, a permission model, hardware-backed key storage, and verified app links. Most real-world Android vulnerabilities do not come from the platform. They come from how an app uses it, such as a component exported by accident, a token stored in plain text, or a WebView that loads more than it should.<\/p>\n
This guide walks through the areas that matter most when securing an Android app, in the order most teams should tackle them. Each section explains the risk, the fix, and what to check before release.<\/p>\n
Quick answer:<\/strong> To secure an Android app, keep secrets on your server, store tokens with Android Keystore, block cleartext traffic, lock down the manifest (no unneeded exported components, debugging off, backups restricted), validate every intent and deep link, restrict WebViews, keep dependencies updated, and verify app integrity on your server with the Play Integrity API.<\/p>\n Anything inside your APK or AAB can be read by anyone who downloads it. That includes BuildConfig fields, strings.xml, assets, and native libraries.<\/p>\n \u2022Keep third-party secret keys on your backend and have the app call your backend instead.<\/p>\n \u2022Issue short-lived, narrowly scoped tokens to the app.<\/p>\n \u2022Restrict any key that must ship (such as a maps key) to your package name and signing certificate in the provider\u2019s console.<\/p>\n This is OWASP\u2019s number one mobile risk. See M1 Improper Credential Usage<\/u> for patterns and fixes.<\/p>\n Each app has a private storage area, but that is not enough for sensitive data. Backups, rooted devices, and debugging tools can expose it.<\/p>\n \u2022Store as little as possible.<\/strong> If the app does not need it offline, keep it on the server.<\/p>\n \u2022Encrypt sensitive values with a Keystore key.<\/strong> The Android Keystore holds keys in secure hardware on most devices, so the key material is never exposed to the app process.<\/p>\n val<\/strong><\/span> spec<\/span> =<\/span> KeyGenParameterSpec.<\/span>Builder(<\/span> val<\/strong><\/span> keyGen<\/span> =<\/span> KeyGenerator.<\/span>getInstance(<\/span>KeyProperties.<\/span>KEY_ALGORITHM_AES,<\/span> “AndroidKeyStore”<\/span>)<\/span> \u2022Never write tokens or personal data to external storage, logs, or the clipboard.<\/strong><\/p>\n \u2022Hide sensitive screens from screenshots and the recent apps view<\/strong> with FLAG_SECURE where it makes sense, such as payment or health screens.<\/p>\n Every request your app makes should be encrypted and validated.<\/p>\n \u2022Block cleartext traffic<\/strong> with a network security config.<\/p>\n \u2022Never override certificate validation<\/strong>, even temporarily for testing. Custom TrustManager or HostnameVerifier code that accepts everything is one of the most common findings in Android apps.<\/p>\n \u2022Pin public keys for high-risk APIs<\/strong> and always include a backup pin so a certificate rotation does not break the app.<\/p>\n <!– res\/xml\/network_security_config.xml –><\/em><\/span> Reference it in the manifest with android:networkSecurityConfig=”@xml\/network_security_config”.<\/p>\n The AndroidManifest.xml defines your app\u2019s attack surface. Review the merged manifest (including what libraries add) before every release.<\/p>\n Setting<\/p>\n Secure default<\/p>\n Why it matters<\/p>\n android:debuggable<\/p>\n Never true in release<\/p>\n A debuggable build lets anyone with USB access inspect and modify the running app<\/p>\n android:allowBackup<\/p>\n false, or use backup rules that exclude sensitive files<\/p>\n Prevents app data from being copied out through backups<\/p>\n android:exported<\/p>\n false unless another app truly needs access<\/p>\n Exported components can be started by any app on the device<\/p>\n android:usesCleartextTraffic<\/p>\n false<\/p>\n Blocks unencrypted HTTP<\/p>\n Permissions<\/p>\n Only what the feature needs<\/p>\n Fewer permissions mean less to abuse and better user trust<\/p>\n Since Android 12, any component with an intent filter must declare android:exported explicitly. Treat that as a prompt to decide each one on purpose.<\/p>\n Activities, services, broadcast receivers, and content providers are entry points into your app.<\/p>\n \u2022Keep components private<\/strong> unless they must be reachable by other apps.<\/p>\n \u2022Protect exported components<\/strong> with a signature-level custom permission when only your own apps need access.<\/p>\n \u2022Treat every incoming intent as untrusted input.<\/strong> Validate extras before using them, and never forward an incoming intent directly to startActivity without checks.<\/p>\n \u2022Use explicit intents<\/strong> to start your own components, and set a package on implicit intents that carry sensitive data.<\/p>\n \u2022Use PendingIntent.FLAG_IMMUTABLE<\/strong> unless the intent must be modified by the receiver.<\/p>\n \u2022Use parameterized queries<\/strong> in content providers and restrict them with permissions.<\/p>\n WebViews bring the web\u2019s risks into your app.<\/p>\n \u2022Load only your own trusted origins, and block navigation to anything else.<\/p>\n \u2022Keep JavaScript disabled unless the page needs it.<\/p>\n \u2022Avoid addJavascriptInterface on any WebView that can load untrusted content.<\/p>\n \u2022Disable file access (setAllowFileAccess(false)) unless you rely on it.<\/p>\n \u2022Never ignore SSL errors in onReceivedSslError.<\/p>\n Custom URL schemes can be claimed by any app, so they are not a safe way to deliver sensitive data like login codes.<\/p>\n \u2022Use verified Android App Links<\/strong> (https links with android:autoVerify=”true” and a matching assetlinks.json on your domain) for anything sensitive.<\/p>\n \u2022Validate every parameter that arrives through a link before acting on it.<\/p>\n \u2022Never let a link parameter decide which URL a WebView loads without an allowlist.<\/p>\n Third-party code runs with your app\u2019s permissions and access to its data.<\/p>\n \u2022Pin dependency versions and review updates.<\/p>\n \u2022Check what each SDK collects and which permissions it adds to the merged manifest.<\/p>\n \u2022Generate a software bill of materials (SBOM) for each release.<\/p>\n \u2022Keep your Google Play Data safety form consistent with what your SDKs actually do.<\/p>\n Checks that run only on the device can be modified by someone who controls the device. For sensitive actions, let your server decide.<\/p>\n The Play Integrity API<\/u><\/a> lets your server verify that a request comes from your genuine app binary, installed through Google Play, on a genuine certified Android device. Use it to protect high-value actions such as sign-up, payments, and promotions, and decide on the server how to respond to a failed verdict.<\/p>\n \u2022Enable R8 code shrinking and obfuscation for release builds. It reduces what is exposed, though it does not protect secrets.<\/p>\n \u2022Strip debug logging from release builds.<\/p>\n \u2022Sign with a key stored securely (Play App Signing or a hardware-backed key store) and restrict who can access it.<\/p>\n \u2022Set minSdkVersion as high as your users allow so you benefit from newer platform protections.<\/p>\n \u2610 No secret keys in code, resources, or build config<\/p>\n \u2610 Sensitive data encrypted with a Keystore key, or not stored at all<\/p>\n \u2610 Cleartext traffic blocked; no custom trust-all certificate code<\/p>\n \u2610 Pinning with backup pins for high-risk APIs<\/p>\n \u2610 debuggable off, backups restricted, each exported reviewed<\/p>\n \u2610 Incoming intents and deep link parameters validated<\/p>\n \u2610 WebViews restricted to trusted origins<\/p>\n \u2610 Verified App Links for sensitive flows<\/p>\n \u2610 Dependencies pinned, SBOM generated, Data safety form accurate<\/p>\n \u2610 High-value actions verified server-side with Play Integrity<\/p>\n \u2610 R8 enabled and debug logs stripped in release<\/p>\n What is the most common Android app security issue?<\/strong> Hardcoded secrets and insecure storage of tokens are among the most common, along with components exported without protection.<\/p>\n Is the Android app sandbox enough to protect user data?<\/strong> It is a strong baseline, but it does not protect against backups, rooted devices, or your own app\u2019s mistakes. Encrypt sensitive data with a Keystore key and store as little as possible.<\/p>\n Does R8 obfuscation make my app secure?<\/strong> No. R8 makes code harder to read and smaller, but it does not hide string values like API keys. Use it as one layer, not as protection for secrets.<\/p>\n Should every Android app use certificate pinning?<\/strong> Not every app. Pinning helps most for apps handling payments, health data, or authentication. Always include a backup pin and an expiration plan.<\/p>\n How does Play Integrity help security?<\/strong> It lets your server confirm that a request comes from your genuine app on a genuine device, so you can protect sensitive actions from modified apps and emulators.<\/p>\n Nandee is an AI-assisted mobile application security testing platform for Android and iOS apps. It checks your build against the issues in this guide and gives your developers prioritized fixes.<\/span><\/p>\n \u2022Android Developers: Play Integrity API overview<\/u><\/a><\/p>\n1. Secrets and credentials<\/h2>\n
2. Secure data storage<\/h2>\n
“session_key”<\/span>,<\/span>
KeyProperties.<\/span>PURPOSE_ENCRYPT or KeyProperties.<\/span>PURPOSE_DECRYPT
)<\/span>
.<\/span>setBlockModes(<\/span>KeyProperties.<\/span>BLOCK_MODE_GCM)<\/span>
.<\/span>setEncryptionPaddings(<\/span>KeyProperties.<\/span>ENCRYPTION_PADDING_NONE)<\/span>
.<\/span>setKeySize(<\/span>256<\/span>)<\/span>
.<\/span>build()<\/span><\/p>\n
keyGen.<\/span>init(<\/span>spec)<\/span>
val<\/strong><\/span> key<\/span> =<\/span> keyGen.<\/span>generateKey()<\/span><\/p>\n3. Network security<\/h2>\n
<network-security-config<\/strong><\/span>>
<base-config<\/strong> cleartextTrafficPermitted=<\/span>“false”<\/span> \/>
<domain-config<\/strong><\/span>>
<domain<\/strong> includeSubdomains=<\/span>“true”<\/span>>api.example.com<\/a><\/domain<\/strong><\/span>>
<pin-set<\/strong> expiration=<\/span>“2027-01-01”<\/span>>
<pin<\/strong> digest=<\/span>“SHA-256”<\/span>>PRIMARY_KEY_HASH_BASE64=<\/pin<\/strong><\/span>>
<pin<\/strong> digest=<\/span>“SHA-256”<\/span>>BACKUP_KEY_HASH_BASE64=<\/pin<\/strong><\/span>>
<\/pin-set<\/strong><\/span>>
<\/domain-config<\/strong><\/span>>
<\/network-security-config<\/strong><\/span>><\/p>\n4. Manifest hardening<\/h2>\n
5. Components and intents<\/h2>\n
6. WebViews<\/h2>\n
7. Deep links and App Links<\/h2>\n
8. Dependencies and SDKs<\/h2>\n
9. App integrity and server-side verification<\/h2>\n
10. Release builds<\/h2>\n
Android security release checklist<\/h2>\n
FAQ<\/h2>\n
Test your Android app<\/h2>\n
Sources<\/h2>\n