Reduce Android Activity Hijack risk by making exported activities as narrow as possible and checking every incoming intent. Require explicit intents for sensitive flows, verify caller identity where feasible, and reject malformed or unexpected extras. Review manifest exposure, test deep links, and monitor for confusing user-interface transitions that could steer users into the wrong activity.
How Android activity hijacking happens
android activity hijack is an app-layer attack path, not just a bad navigation bug. It becomes possible when one activity can be launched or influenced outside the intended trust boundary, often through exported components, implicit intent handling, deep links, or overly broad intent filters. The core question is whether a different app, link, or user action can steer the victim into the wrong screen with the wrong data or authority.
That matters because the hijacked activity may inherit user trust, session state, or sensitive workflow context. If a sensitive flow can be reached without a precise entry condition, the attacker does not need to break Android itself, only the assumptions your app makes about who started the activity and what the incoming parameters mean.
Two design choices usually create the opening: activities exposed more widely than necessary, and code that treats every intent as trustworthy. Tightening either one reduces the attack surface, but the strongest result comes from treating launch path, caller, and extras as security-relevant inputs rather than convenience details.
Which mitigations change the attack surface most
The highest-value mitigation is to make exported activities as narrow as possible and keep sensitive functionality behind explicit, intended launch paths. If an activity does not need to be opened from outside the app, do not export it. If it must be reachable externally, reduce the accepted launch conditions so that only the specific flow, caller pattern, or data shape you expect can open it.
Intent handling should be defensive by default. Check every incoming intent, reject malformed or unexpected extras, and require explicit intents for sensitive flows whenever you can. For flows that depend on trust, verify caller identity where feasible so the app can distinguish a legitimate internal transition from a crafted external launch. This is especially important when the activity performs account actions, displays private data, or changes state.
Deep links deserve the same scrutiny as activities because they often become indirect entry points into the same code path. Test the manifest exposure, then test the full path from link or intent to screen transition to confirm the app does not accept alternate routes that bypass your intended checks. Mobile App Security Guide is a useful reference for the broader mobile control set around intent handling, deep links, and activity exposure.
What usually fails in practice
Activity hijack often succeeds because the app is secure at the component level but weak at the transition level. Developers protect the activity body yet forget that the launch event itself can be manipulated, especially when multiple activities share similar names, accept broadly structured extras, or present a user interface that looks like a legitimate next step.
Confusing user-interface transitions are a real risk because users may be nudged into granting consent, confirming a payment, or approving a state change in the wrong activity. If the screen looks familiar but the launch context is attacker-controlled, the app can produce the appearance of continuity while silently shifting control to the attacker’s chosen path.
That is why review work should focus on boundaries, not just code branches. Manifest declarations, intent filters, deep link handlers, and any screen that can be reached from outside the app should be tested together as one access path. The right question is not only “does the activity work,” but “can anything else reach this screen with the wrong authority or the wrong payload?”
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP ASVS, CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V4 — API and Web Service | Activity launches and deep links need strict input and request validation. |
| V8 — Authorization | Sensitive Android flows need caller-aware access decisions and least-privilege reachability. | |
| V13 — Configuration | Manifest exposure and intent filters are configuration choices that shape attack surface. | |
| Recommendation — Apply V4 validation to reject unexpected activity inputs and launch parameters. Enforce V8 checks so only intended callers can reach sensitive activity flows. Review V13 settings to keep exported activities and filters as narrow as possible. | ||
| CIS Controls v8 | CIS-16 — Application Software Security | This is an application security weakness driven by insecure launch-path design. |
| Recommendation — Use CIS-16 to test and harden mobile launch paths, deep links, and component exposure. | ||
| NIST SP 800-53 Rev 5 | CM-7 — Least Functionality | Minimising exported activities follows the least-functionality principle. |
| Recommendation — Limit exposed activities and interfaces to only the functions that must be reachable. | ||
Practitioner Guidance
What to verify: Confirm which activities are actually exported, which ones are reachable through deep links or implicit intents, and whether any sensitive flow accepts parameters that change account, payment, or privilege state without strong validation.
What good looks like: External entry points are limited to the smallest possible set, sensitive screens require explicit launch conditions, and unexpected extras fail closed instead of being tolerated or ignored.
Common mistake: Teams often secure the visible business logic but leave the launch surface broad, which means the app still trusts attacker-shaped context before the first line of sensitive code runs.
Practitioner takeaway: Treat activity launch as part of the security boundary, because once an untrusted caller can shape the navigation path, later checks are already operating on attacker-chosen context.