Android App Security: Preventing Common Vulnerabilities

Most Android security incidents aren't clever attacks on novel weaknesses. They're the same handful of avoidable mistakes, shipped over and over. The good news for a solo developer is that preventing the common vulnerabilities is mostly discipline, not deep security expertise. Here are the ones I actively guard against on every app.

Lock Down Exported Components

The most frequent real-world Android leak is an

Activity

Service

BroadcastReceiver

<activity android:name=".InternalActivity" android:exported="false" />

Audit your merged manifest, not just your own file — libraries can add exported components you didn't write.

Never Trust an Incoming Intent

An intent from outside your app is untrusted input. If you read an extra and use it to load a file, navigate, or grant access, an attacker can craft a malicious intent. Validate every value that crosses that boundary, and never use an incoming intent to construct a file path or a privileged action without checking it. The same applies to deep links — a deep link is a URL a stranger can send your app, so treat its parameters as hostile until proven safe.

Store Sensitive Data Encrypted

Plain

SharedPreferences

Keep Communication Secure

All network traffic is HTTPS, and I block cleartext explicitly in the network security config so a misconfigured endpoint can't silently downgrade to plain HTTP. For high-value endpoints, certificate pinning raises the bar against man-in-the-middle attacks on hostile networks. Transport security is foundational — if the channel isn't secure, nothing you do on either end matters.

Minimize Permissions and Data

Every permission you request and every field you collect is both an attack surface and a liability you must declare. I request the minimum permissions the feature needs and drop any that a refactor made unnecessary. The same goes for data: collecting less means less to leak, less to secure, and a simpler data safety declaration. Security and privacy reinforce each other here — the leanest app is also the most defensible one.

Make Security Part of the Workflow

The reason these vulnerabilities ship isn't that they're hard to prevent; it's that nobody looks until something goes wrong. I fold the checks into normal work: a credential scan runs before commits so secrets can't sneak into git, I review the manifest's exported components before release, and I treat any new boundary — an intent, a deep link, a stored secret — as a moment to ask the security question while the fix is still cheap. None of this requires being a security researcher. It requires building the habit of asking, at each boundary, what an attacker could do with it, and closing the obvious doors before they ship.

It helps to remember that attackers are economically rational: they go for the easy, high-reward targets, not the hardest ones. Most of the vulnerabilities here are easy wins for an attacker precisely because they're so common, which means closing them moves your app out of the "low effort, decent payoff" bucket that opportunistic attacks target. You don't need to be unbreakable; you need to be enough of a hassle that it's not worth the trouble compared to the next app. That's an achievable bar for a solo developer, and it's reached not through heroics but through the boring consistency of doing these basics on every release, so a vulnerability never quietly slips through while your attention was elsewhere.

Key Takeaways

• Export components only when another app must call them, protect exported ones with permissions, and audit the merged manifest.
• Treat incoming intents and deep links as untrusted input; validate every value before acting on it.
• Store sensitive data in Keystore-backed encrypted storage, and question whether you need to persist it at all.
• Enforce HTTPS, block cleartext in the network security config, and pin certs for sensitive endpoints.
• Request the minimum permissions and collect the minimum data — less surface, less liability, simpler declarations.
• Build the security check into your normal workflow so the common mistakes get caught while fixes are cheap.