Intents are how Android components talk to each other, and they come in two kinds. An explicit intent names exactly which component should receive it; an implicit intent just describes an action and lets the system pick an app that can handle it. Implicit intents are great for "open this in a browser" style interactions, but they carry a risk: because any app can declare it handles a given action, a malicious app can register to receive your implicit intents and read whatever you put in them. If that includes sensitive data, you have leaked it. Here is what implicit intents are, where interception happens, and how to use intents safely.
Short answer
An implicit intent specifies an action rather than a specific target component, so the system resolves it to any app whose intent filter matches, which means a malicious app can register to receive your implicit intents and read their contents. Per Android, the risk is that sensitive data placed in an implicit intent, or an implicit intent used for internal or sensitive communication, can be intercepted by another app, and implicit intents are also unsuitable for binding services. The fix is to use explicit intents for internal and sensitive communication, avoid putting sensitive data in implicit intents, restrict an intent's recipient where appropriate, and protect broadcasts with permissions. Send sensitive things to a component you name, not to whoever the system resolves.
What you should know
- Implicit intents specify an action, not a target: the system resolves the recipient.
- Any matching app can receive them: including a malicious one.
- Sensitive data in an implicit intent can leak: another app reads it.
- Use explicit intents internally: name the component for sensitive communication.
- Protect broadcasts and restrict recipients: permissions and an explicit package.
What are implicit intents, and what is the risk?
An implicit intent describes what you want done and lets Android decide which app does it. Instead of naming a target component, it carries an action, and possibly data and a category, and the system finds apps whose intent filters match, presenting a chooser or launching the handler. This is the right tool for interacting with other apps generically, opening a web page, sharing content, where you do not know or care which specific app responds. The risk arises from that openness: because any app can declare an intent filter matching a given action, a malicious app can register to receive implicit intents for it, and if your implicit intent carries sensitive data, that app can read it. The same openness makes implicit intents wrong for internal communication between your own components, where you know the exact recipient, and unsuitable for binding services, since the resolution is ambiguous. So the risk is that an implicit intent goes to whoever matches, which may not be who you intended, and exposes whatever it contains to that recipient.
Where does interception happen?
In the common implicit-intent paths, when another app matches. The table lists them.
| Path | Interception risk |
|---|---|
| Implicit intent with sensitive data | A matching malicious app reads the contents |
| Internal communication via implicit intent | Another app receives what should stay in-app |
| Implicit broadcast | An unprotected broadcast is read by other apps |
| Service bound implicitly | Ambiguous resolution; disallowed for binding |
| Mutable PendingIntent | A handed-out intent altered by the receiver |
The core case is an implicit intent carrying sensitive data: since resolution is by matching intent filter, a malicious app that declares the matching filter can be the recipient and read the data, whether that is a direct intent or a broadcast. Using an implicit intent for communication that should stay within your own app is a related mistake, sending in-app data out to whatever app matches. Implicit broadcasts that are not protected by a permission can be received by other apps. Implicit intents are also disallowed for binding services because the recipient would be ambiguous. And a related concern is PendingIntent: a mutable one handed to another component can be modified by the receiver, so PendingIntents should generally be immutable unless mutability is genuinely required. Each comes back to the recipient not being who you assumed.
How do you use intents safely?
Name the recipient for sensitive or internal communication, and protect the rest. For communication between your own components, use explicit intents that name the exact target component, rather than implicit intents, so the message cannot be received by another app. Do not place sensitive data in an implicit intent at all; if an interaction must be implicit, keep its contents non-sensitive. Where you use an implicit intent but want to restrict who can handle it, set the package so it is delivered only to a specific app, which narrows an implicit intent toward an explicit recipient. Protect broadcasts that carry anything sensitive with permissions, or use a delivery mechanism scoped to your app, rather than sending an unprotected implicit broadcast. Use explicit intents for services. And make PendingIntents immutable unless you specifically need them mutable, so a recipient cannot alter them. The principle is that anything sensitive, or meant to stay within your app, should be sent to a component you explicitly name, while implicit intents are reserved for genuinely generic interactions with non-sensitive contents.
What to watch out for
The first trap is putting sensitive data in an implicit intent, where a malicious app declaring the matching filter can read it; use an explicit intent and keep implicit ones non-sensitive. The second is using implicit intents for internal communication that should never leave your app; name the component. The third is unprotected implicit broadcasts and mutable PendingIntents. Intent usage is in your manifest and code, so a pre-submission scan such as PTKD.com (https://ptkd.com), which reads the compiled APK or AAB against OWASP MASVS, surfaces your components and how the app handles intents and inter-app communication, helping you confirm sensitive communication is explicit. The intent choices you make in code.
What to take away
- An implicit intent specifies an action and lets the system resolve the recipient, so any matching app, including a malicious one, can receive it and read its contents.
- Sensitive data in an implicit intent, internal communication via implicit intents, and unprotected implicit broadcasts can all be intercepted by another app.
- Use explicit intents that name the component for internal and sensitive communication, keep implicit intents non-sensitive, restrict recipients with a package or permissions, and make PendingIntents immutable.
- Use a pre-submission scan such as PTKD.com to surface how your app handles intents and inter-app communication, then make sensitive communication explicit.
