Android Exported Components: The Attack Surface You Ship by Accident

Android’s inter-process communication model is one of the platform’s genuine strengths and one of its most reliable sources of findings. The mechanism that lets your app share a photo with a messaging app is the same mechanism that lets a malicious app on the same device reach into your components.

The question in every assessment is which components are reachable from outside your app, and what they do when they are reached.

The four component types

Activities are screens. An exported activity can be launched by any app. The classic finding is an activity that displays sensitive content and assumes the user navigated to it through your login flow — launched directly, it renders without the session check that lived on the previous screen.

Services perform background work. An exported service accepting commands via intent extras is an API, and it is rarely treated like one. We find services that will perform privileged operations for any caller because the developer reasoned that only their own app would ever bind to it.

Broadcast receivers react to system or app events. An exported receiver accepts broadcasts from anywhere. Where the receiver acts on data in the intent — a deep link, a configuration change, a notification action — that data is attacker-controlled.

Content providers expose structured data and are the highest-value target of the four. An exported provider with a permissive URI matcher can expose the app’s database. Providers that pass a selection string into a raw query are vulnerable to SQL injection from another app on the device — an old flaw that keeps reappearing.

Why it happens

Mostly defaults and inheritance.

Any component declaring an intent filter is exported by default unless explicitly set otherwise. That is a sensible default for a share target and a poor one for an internal screen that happens to have a filter for deep linking.

Third-party SDKs contribute components to your merged manifest. Your app ships whatever they declared, and the merged manifest is not something most teams read. Checking it is a five-minute job that we perform on every Android assessment and that most teams have never done.

And targetSdkVersion changes behaviour. From API 31, components with intent filters must declare android:exported explicitly — which surfaces the decision, but often results in developers setting true to make the build pass.

How it is tested

1. Decompile the APK and read the merged manifest. Enumerate every component and its exported status, permissions and intent filters.
2. For each exported component, attempt invocation from an unprivileged test app. Not adb alone — adb shell am runs with shell privileges and will succeed where a real attacking app fails, which produces false positives.
3. Fuzz intent extras. Missing extras, wrong types, oversized values, and values crossing a trust boundary.
4. For content providers, enumerate the URI space and test the selection and projection parameters for injection.
5. Check for intent redirection — a component that accepts an intent as an extra and forwards it, letting an attacker reach internal components through your app’s privileges.

The remediation

Default everything to android:exported="false" and export only what genuinely needs to be reachable. Anything that must be exported and is not intended for arbitrary callers should require a signature-level permission, which restricts it to apps signed with your key.

Treat every exported component as an unauthenticated API endpoint. Validate the input, check the caller, and do not assume the intent came from your own UI. That framing tends to produce better decisions than a manifest review does.