An Android component that can be reached by other apps on the device because it is marked as externally accessible or registered without adequate protection. In practice, exported components create an attack path if they expose sensitive actions, data, or navigation flows without proper permission checks.
Expanded Definition
An exported Android component is any activity, service, broadcast receiver, or content provider that other apps can reach across the app boundary. In mobile security terms, the key issue is not simply that the component is reachable, but whether its entry conditions, permissions, and data handling are strong enough to prevent unauthorised use.
Definitions vary across vendors and secure coding guidance, but the practical NHI security lens is consistent: exported components become control points for app-to-app interaction, and therefore for abuse of embedded credentials, session tokens, device-local data, and privileged workflows. Android’s own security model emphasises explicit exposure and permission gating, while broader governance frameworks such as the NIST Cybersecurity Framework 2.0 reinforce the need to manage external access paths deliberately rather than by default.
In NHI-heavy mobile estates, an exported component may act as a bridge into backend APIs, local secret stores, or onboarding flows that mint credentials. The most common misapplication is assuming a component is safe because it was intended for internal use, which occurs when developers forget that an exported declaration or missing permission check makes it reachable from any app on the device.
Examples and Use Cases
Implementing exported component controls rigorously often introduces some friction for developers, requiring organisations to weigh interoperability and app extensibility against attack surface reduction.
- A login callback activity is exported so a companion app can return control after authentication, but it also exposes navigation states that should have remained private.
- An exported service accepts intents from other apps and triggers backend actions, creating a path to misuse if it does not validate caller identity and request scope.
- A content provider shares app data with approved partners, but weak URI permissions allow broader read access than intended.
- A broadcast receiver listens for system or third-party events, yet it processes sensitive signals without checking who sent the broadcast or whether the payload is trusted.
- Mobile threat modelling for this pattern should be paired with NHI lifecycle governance, especially where an app can initiate token retrieval or credential-dependent actions, a risk profile discussed in Ultimate Guide to NHIs and reflected in secure identity guidance from the NIST Cybersecurity Framework 2.0.
Why It Matters in NHI Security
Exported components matter in NHI security because they can expose the exact pathways attackers use to pivot from a mobile app into identities, secrets, and privileged API operations. When those components are reachable without strict permission checks, they can become a practical exfiltration route for tokens, certificates, or session material that was meant to stay inside the app boundary. That risk is especially important in ecosystems where mobile apps are used to administer services, approve actions, or broker access to backend platforms.
NHIMG research shows that 96% of organisations store secrets outside secrets managers in vulnerable locations, and 79% have experienced secrets leaks, with 77% of those incidents causing tangible damage, according to the Ultimate Guide to NHIs. In practice, an exported component can become the front door to that wider weakness when it can launch flows that reveal or reuse secrets. Security teams should treat exported surfaces as part of identity governance, not only application hardening, and tie them to least privilege, caller validation, and explicit permission design. Organisations typically encounter the operational impact only after an app is abused to trigger unauthorised actions or leak credentials, at which point the exported component becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Exported components can expose NHI entry points and sensitive actions to untrusted callers. |
| OWASP Agentic AI Top 10 | A-03 | Agentic workflows may invoke mobile components and inherit their exposure risks. |
| NIST CSF 2.0 | PR.AA | Identity and access control practices apply to externally exposed application entry points. |
| NIST Zero Trust (SP 800-207) | JA.1 | Zero Trust requires explicit verification before granting access across app boundaries. |
| NIST SP 800-63 | Identity assurance principles inform how apps should validate requests tied to credentials. |
Restrict external reachability and validate caller authorization before any NHI-related action runs.
Related resources from NHI Mgmt Group
- What breaks when a GitHub Actions workflow component is compromised?
- What is the difference between identity infrastructure and a login component?
- What breaks when sensitive data is passed from a Server Component to a Client Component?
- What is the main risk of giving AI access to component hierarchies and style mappings?
