Intents are how Android components talk to each other, and how they get attacked. Two related problems show up often: an app that receives an Intent and forwards it without checking, letting an attacker reach internal components through your app, and an app that sends sensitive data in an implicit Intent that another app can intercept. Both come down to trusting Intents that should not be trusted. Google Play even flags intent redirection as a security issue. Here is what these attacks are and how to handle Intents so your app is not the path an attacker uses.
Short answer
Intent redirection happens when your app takes an Intent it received and launches or forwards it without validating it, letting an attacker use your app to reach its internal components or act with its privileges. Per Android's guidance, the related risks are sending sensitive data via implicit Intents that another app can intercept, and using mutable PendingIntents that another app can tamper with. The fixes are to validate Intents you receive before acting on them, use explicit Intents for sensitive internal communication, and make PendingIntents immutable. Treat any Intent that crosses an app boundary as untrusted input, since that is what turns Intents from a feature into an attack path.
What you should know
- Intent redirection forwards untrusted Intents: reaching internal components.
- Implicit Intents can be intercepted: another app registers a matching filter.
- Mutable PendingIntents are risky: another app can tamper with them.
- Validate received Intents: especially in exported components.
- Use explicit Intents for sensitive cases: target your own component directly.
What is intent redirection and hijacking?
They are two ways Intents become an attack vector. Intent redirection, sometimes called Intent forwarding, occurs when your app receives an Intent, often through an exported component, and then uses data from it to start another component without validating it, so an attacker can craft an Intent that your app dutifully forwards to one of your internal components, reaching functionality the attacker could not invoke directly. Intent hijacking is the interception side: when your app sends an implicit Intent, one that names an action rather than a specific component, any app that registered a matching intent filter can receive it, so sensitive data in that Intent can be captured by a malicious app. Both stem from the same root, trusting an Intent, either one your app received from outside or one you broadcast without targeting, when Intents that cross app boundaries are attacker-controllable.
Where does it go wrong?
In a few recognizable patterns. The table lists them.
| Pattern | Risk |
|---|---|
| Forwarding a received Intent without validation | Attacker reaches your internal components through your app |
| Sending sensitive data in an implicit Intent | Another app can intercept it |
| Mutable PendingIntent handed to another component | The other app can modify it and act as your app |
| Trusting extras from an incoming Intent | Crafted input drives sensitive behavior |
The redirection case is the one Google Play specifically flags: an exported component takes an Intent and launches another component based on it, so a malicious app supplies an Intent that gets forwarded internally. The implicit-Intent case leaks data outward, and the mutable PendingIntent case lets another app fill in or change the Intent and have it run with your app's identity, which is why Android now requires PendingIntents to specify mutability.
How do you handle Intents safely?
Validate what you receive, target what you send, and lock down PendingIntents. For any Intent your app receives, especially in an exported component, validate it before acting: check that it is what you expect, do not blindly trust its extras, and do not forward it to an internal component without confirming the destination and data are safe. For sensitive internal communication, use explicit Intents that name your own component directly, rather than implicit Intents that any app can intercept, and do not put sensitive data in an implicit Intent. When you create a PendingIntent, mark it immutable with the immutable flag, which is required on recent Android, so another component cannot modify it. The throughline is to treat every Intent that crosses an app boundary as untrusted input, the same way you would treat data from the network.
What to watch out for
The first trap is forwarding a received Intent to an internal component without validation, the redirection pattern Google Play flags; validate and constrain the destination. The second is sending sensitive data in an implicit Intent, where another app can intercept it; use an explicit Intent. The third is a mutable PendingIntent, which another app can tamper with; make it immutable. A pre-submission scan such as PTKD.com (https://ptkd.com) reads the compiled APK or AAB against OWASP MASVS and surfaces your components, intent handling, and PendingIntent usage, so you can find an intent-redirection or implicit-Intent issue before it ships. Validating Intents and using explicit, immutable ones is the fix.
What to take away
- Intent redirection is forwarding a received Intent without validation, letting an attacker reach your internal components; intent hijacking is another app intercepting an implicit Intent.
- The risky patterns are unvalidated forwarding, sensitive data in implicit Intents, and mutable PendingIntents.
- Validate Intents you receive, use explicit Intents for sensitive internal communication, and make PendingIntents immutable.
- Treat every cross-app Intent as untrusted input, and use a pre-submission scan such as PTKD.com to surface intent-handling issues before launch.
