Join our Newsletter — 33% off our NHI Course

Android Intent Injection

Android Intent Injection is a vulnerability where an attacker supplies or modifies an Intent so an app performs an unintended action or reaches a sensitive component. It can lead to data leakage, privilege misuse, or unsafe component invocation. Defenders should validate input, avoid trusting caller-controlled extras, and protect exported activities, services, and receivers.

What Android Intent Injection Means in Practice

Android Intent Injection is an application-layer weakness where untrusted input influences an OWASP Top 10-style trust boundary inside a mobile app, causing the app to invoke the wrong component, pass unsafe extras, or trigger functionality the developer did not intend. The core issue is not the Intent object itself, but the failure to treat caller-controlled data as hostile until validated.

In practice, this often appears when an activity, service, broadcast receiver, deep link handler, or exported component accepts parameters and then forwards them into a privileged action. If the app assumes the caller is benign, an attacker can steer execution into sensitive code paths, alter routing, or bypass intended workflow checks.

Why It Becomes Dangerous

The danger comes from how much authority a mobile component may already have. A single injected Intent can expose user data, alter application state, or make a protected capability reachable from outside the app. That is why Android component exposure, especially on exported entry points, deserves the same scrutiny as any other externally reachable interface.

Intent injection is especially harmful when the receiving component performs file access, account actions, token handling, or internal navigation based on caller-supplied fields. Once the app accepts that data without strict allowlisting, the attacker is no longer limited to view changes, they may be able to influence business logic or reach internal-only functionality.

How Attackers Abuse Intents

Attackers typically look for exported activities, services, and receivers that trust extras, actions, data URIs, or component names. They then craft a malicious Intent to change the destination, override parameters, or invoke code paths that should only be reachable from inside the app. The same pattern can also be used to force the app to open sensitive screens or leak data through unintended responses.

In mobile ecosystems, this is often paired with other issues such as weak exported-component design, unsafe deep-link handling, or implicit trust in intent flags. For a broader testing perspective, NHIMG’s Mobile App Security Testing Guide is useful when you need to validate component exposure, runtime behaviour, and Android-specific abuse paths. A more general Mobile App Security Guide also helps place Intent handling alongside storage, attestation, and platform-hardening concerns.

Defensive Design and Verification

Defence starts with reducing what an external caller can influence. Components should be exported only when necessary, and every Intent parameter should be treated as untrusted input that requires allowlisting, type checking, and explicit validation. Security-sensitive decisions should never be driven only by the caller’s chosen action string, component reference, or extras.

Testing should focus on component reachability, parameter tampering, and whether sensitive flows remain protected when invoked from outside the expected app context. Where possible, use explicit Intents, enforce permission checks, and ensure that internal-only behaviour cannot be reached through generic Android messaging patterns. The goal is to make the app fail closed when the caller is unknown, malformed, or outside the intended trust boundary.

Risk and Threat Considerations

Intent injection creates a direct path from untrusted input to application behaviour, which makes it a practical route to data exposure, unauthorised actions, and workflow abuse. The same weakness can also undermine component isolation, especially when multiple apps or app modules share the same device trust boundary.

Failure mechanism: An attacker supplies a crafted Intent, or modifies one in transit, so the app processes attacker-chosen routing, extras, or component targets instead of the developer’s intended values.

Impact: The app may leak sensitive data, invoke privileged functions, bypass navigation or authorisation checks, or expose internal components to external abuse.

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 V2 — Validation and Business Logic Intent parameters drive app logic, so validation and safe branching are central here.
V8 — Authorization Injected Intents can reach protected functions, making access checks and authorised flow control material.
V13 — Configuration Exported component exposure and Android manifest settings shape whether Intents can be abused externally.
Recommendation — Validate all caller-controlled Intent data before it influences any security-relevant action. Enforce authorisation checks before sensitive components execute or disclose data. Harden component exposure and remove unnecessary externally reachable entry points.
CIS Controls v8 CIS-16 — Application Software Security The weakness is an application design and verification problem in mobile software.
Recommendation — Test mobile components for unsafe input handling and unintended exposed functionality.
NIST SP 800-53 Rev 5 SA-11 — Developer Testing and Evaluation Intent injection is best caught through security testing of externally reachable app behaviour.
Recommendation — Exercise hostile Intent inputs during security testing to verify components fail safely.

Practitioner Guidance

What to watch for: Review any component that accepts external Intents, deep links, or cross-app calls, especially when those inputs influence state changes, account actions, or sensitive rendering. If a screen or service works only because the caller behaves “correctly,” it is likely relying on a trust assumption that should be made explicit.

Practitioner takeaway: Treat every externally reachable Android component as an attack surface, and validate the Intent first, not after the app has already made a security-relevant decision.