TL;DR: Android app risk often comes from misconfiguration rather than code, with exported components, weak permissions, intent redirection, and task hijacking creating exploitable exposure across the app lifecycle, according to Appknox. The practical lesson is that security teams need continuous validation of what an app exposes, not just one-time scanning of what it contains.
NHIMG editorial — based on content published by Appknox: Android Component Security: Common Misconfigurations That Expose Mobile Apps
Questions worth separating out
Q: What breaks when Android app components are exposed without protection?
A: When Android components are exposed without protection, any other app may be able to launch them, send data to them, or trigger sensitive actions.
Q: Why do weak Android permissions create a real security gap?
A: Weak Android permissions create a gap because normal and dangerous protection levels do not enforce strong trust boundaries.
Q: How can security teams tell whether Android configuration controls are working?
A: Teams should verify whether the app’s exposed surface matches its intended trust model across builds and releases.
Practitioner guidance
- Audit exported components across the manifest Review every Activity, Service, Broadcast Receiver, and Content Provider for exported=true, then confirm each one has a justified business need and an explicit protection control.
- Enforce signature-level protection for sensitive permissions Replace normal and dangerous custom permissions with signature where the component should only be callable by trusted apps signed with the same certificate.
- Validate nested Intents before forwarding them Require allowlist checks for component names, actions, and extras before calling startActivity or related APIs on an incoming Intent.
What's in the full article
Appknox's full blog covers the implementation detail this post intentionally leaves for the source:
- Manifest-level examples for exported Activities, Services, Broadcast Receivers, and Content Providers
- Code-level intent validation patterns for nested Intents and component forwarding
- ADB-based exploit demonstrations that show how exposed components are abused in practice
- Configuration checks for taskAffinity, permissions, and inter-app communication across the app lifecycle
👉 Read Appknox's analysis of Android component security misconfigurations →
Android component exposure: what IAM and appsec teams miss?
Explore further