The Android developer’s guide to mobile app security

Security isn’t something you add to an Android app after launch. It’s a discipline that runs
through every architectural decision: how traffic flows, which components are exposed, how
dependencies are sourced, and how your release artifact is signed before it reaches any device.
For teams distributing through channels like Indus Appstore, this has direct policy consequences.
Indus’ developer policy explicitly prohibits malware, harmful code, unauthorised access,
privilege escalation, and unconsented device changes. The developer terms also state that
submitted apps may be tested and reviewed for security requirements. That means a weak mobile
app security posture isn’t just engineering debt — it can become a publishing blocker before your
app reaches a single user.
Here’s what Android app security actually covers, and how to make it part of your release
workflow from the start.

What mobile app security actually covers

Many teams associate mobile app security with malware detection or a pre-submission scan. In
practice, it covers far more ground.
Android’s security documentation and OWASP’s Mobile Application Security Verification
Standard (MASVS) both frame it as a full-stack discipline. It includes secure networking and
data storage, least-privilege permissions, controlled inter-process communication (IPC), input
validation, WebView configuration, release signing, and ongoing dependency hygiene. Each of
these areas can introduce real-world risk if handled carelessly.
For developers already thinking carefully about architecture — for instance, applying the
approach described in building robust Android apps with SOLID principles — android app
security fits the same mindset: clear boundaries, controlled access, and minimal exposure. A
component that isn’t exported can’t be exploited by another app. An API call that enforces
HTTPS can’t be silently intercepted. Security is architecture, applied consistently.

Secure networking and transport configuration

Configuring trust deliberately
Android’s Network Security Configuration lets you define per-domain trust settings
declaratively, without custom code. You can disable cleartext traffic across the app, set custom
trust anchors, opt into certificate transparency, and restrict debug-only overrides to debug builds
so they never ship to production.
One common point of confusion: many security checklists still treat certificate pinning as
standard practice. Current Android guidance is explicit — certificate pinning is not
recommended for Android apps. If your transport security strategy relies on it, it’s worth
revisiting before it creates maintenance problems down the line.
The core principle is straightforward: use HTTPS, opt out of cleartext traffic at the configuration
level, and keep debug overrides where they belong.

Lock down your components and harden WebView

Exposed components and IPC boundaries
Android’s security guidance recommends using explicit intents for services, applying signature-
level permissions when sharing data between apps under the same signing key, and explicitly
disabling export on ContentProviders, receivers, and services that don’t need cross-app access.
Overexposed app components are a consistent android app security risk, and one that’s easy to
overlook during a fast-moving build cycle.

WebView risks deserve specific attention
WebView is a recurring risk area. Android guidance recommends disabling JavaScript unless it’s
genuinely required, and treating addJavascriptInterface() with real caution — because the
app can’t verify the origin of code running inside a WebView frame. Insecure WebView native
bridges are a documented vulnerability class. Restricting local file access and blocking cleartext
loading in WebView configurations are additional controls worth applying by default.

App security testing goes deeper than a scanner

OWASP’s Mobile Application Security Testing Guide (MASTG) defines mobile app security
testing as a combination of static and dynamic analysis. Crucially, it frames this as a broader
assessment that typically extends to backend APIs and server-side surfaces — not just the app
binary in isolation.
A complete app security testing workflow covers:
– Static code and configuration analysis
– Dynamic testing of runtime app behaviour
– Review of authentication, session handling, and API surfaces
– WebView and inter-app interaction testing
– Dependency and supply-chain review
– Release artifact validation
– Retesting after significant changes or SDK updates
Running a single automated scanner before submission doesn’t satisfy this scope. Automated
tools are useful, but they don’t replace runtime testing, third-party SDK review, or validating
how sensitive flows behave under adversarial conditions. Mobile application security testing is a
process, not a single pass.

Signing, supply-chain security, and mobile app security for
alternative distribution

Signing and key protection
All APKs must be digitally signed before they can be installed or updated on Android. When
distributing through alternative channels, signing-key management is the developer’s
responsibility. A compromised keystore can allow a malicious build to be distributed under your
identity, so access controls and backup procedures matter as much as the signing step itself.

For Indus Appstore submissions specifically, pre-upload screening against the policy’s prohibited
behaviours — malware, harmful code, sandbox-breaking, and privilege escalation — is sensible
practice. Indus’ developer terms confirm that submitted products may be reviewed for security
requirements, so catching these issues before upload avoids submission delays.
Build-chain and dependency security
Mobile application security extends to your build process. Android’s dependency verification
documentation notes that compromised Gradle dependencies can affect runtime behaviour on
device or execute commands on the build machine itself. Validating dependency checksums and
signatures through Gradle metadata — rather than relying on package resolution defaults — is a
practical control that belongs in your CI/CD pipeline.
A secure app binary is only as trustworthy as the tools and libraries that built it.

Start with security, not after it

Mobile app security isn’t a gate at the end of your release process. It’s the sum of decisions made
at every stage: how components are configured, how traffic is controlled, how dependencies are
verified, and how your artifact is signed and protected before distribution.
For teams publishing on Indus Appstore or any Android channel, those decisions also carry
direct policy implications. Security defects that slip through to submission don’t just create user
risk — they can stall your app’s availability entirely.
Build security in early, test it thoroughly, and treat it as an ongoing practice rather than a pre-
launch checklist.

FAQs

What does mobile app security include for Android teams?
It covers secure networking, least-privilege permissions, component exposure control, input
validation, WebView hardening, release signing, and dependency hygiene. It’s a full engineering
discipline, not just malware prevention or a pre-submission scan.
What’s the difference between mobile application security and app security testing?
Mobile application security is the broader discipline — the set of controls and architectural
decisions built into the app. App security testing is the verification process: static and dynamic
analysis, API review, and runtime behaviour testing, typically conducted as part of a wider
security assessment.

Should Android apps use certificate pinning?
No. Current Android guidance explicitly states that certificate pinning isn’t recommended for
Android apps. Despite appearing on many security checklists, it’s not what official Android
documentation advises.
What are the most common android app security mistakes?
Cleartext traffic in production builds, overexposed components (services, receivers, and
ContentProviders), unsafe WebView settings such as enabled JavaScript or unrestricted file
access, insufficient input validation, and unverified build dependencies are all directly identified
in Android’s security guidance.
Does Indus Appstore publish developer-facing security tooling?
Indus Appstore’s public policy and developer terms pages clearly document security obligations
and the platform’s right to review submissions, but they don’t currently publish detailed
developer-facing security tooling such as attestation APIs or security analytics dashboards.
Developers should refer to the official policy pages for current compliance requirements.
Can the Play Integrity API be used as a universal Android security control across all
distribution channels?
No. Google frames the Play Integrity API around genuine, unmodified apps installed through
Google Play on genuine, certified Android devices. It’s a useful anti-abuse signal for Play-
distributed apps, but it isn’t a store-agnostic attestation layer. Developers distributing through
alternative channels should assess what integrity controls fit their specific distribution context.