What happens when an Android app sends back an unvalidated intent that includes FileProvider URIs?

Why Unvalidated Intent Reflection Becomes a File Exfiltration Primitive

When an Android app reflects an incoming intent without validating what it contains, the app can become part of the attacker’s delivery path rather than a filter on that path. The dangerous detail here is not just that a URI is present, but that FileProvider URIs can be returned with access grants attached. That turns a normal inter-app handoff into an unintended read capability for content the victim app assumed was private.

For security teams, the important distinction is that this is an authorization failure, not a simple parsing bug. The app is not merely processing untrusted data incorrectly; it is reissuing a capability to another process on the same device. That means the exposure depends on how the app handles intent extras, URI permissions, and any logic that preserves flags during reflection. Android’s own documentation on FileProvider explains the intended sharing model, but the risk appears when apps forward or mirror untrusted inputs instead of constraining them. In practice, many teams notice the problem only after testing inter-app flows, rather than during design review.

How the URI and Grant Travel Through the App

An intent can carry both a target URI and permission flags. If the receiving app treats the incoming intent as trustworthy and sends it back unchanged, the same URI can come back with the same grant semantics that were attached on the way in. That matters most when the URI resolves to a FileProvider-backed path inside the victim app’s storage, because the receiving app may now have a readable reference to content it never created or should not have exposed.

The mechanics are usually straightforward:

• The attacker supplies an intent that includes a crafted URI reference.
• The victim app receives the intent and reflects it, reusing the payload instead of validating it.
• Android grants access based on the URI and the preserved permission flags.
• A malicious app can then read the returned content if the grant is effective on that device and for that URI scope.

The security lesson is that the app must validate both the intent source and the semantic meaning of the URI, not just whether the URI string is well-formed. Developers often focus on content-provider exposure or manifest permissions, but the weaker point is the app logic that acts as a relay for access. If the app only intended to echo benign metadata, it should strip permissions and reject any URI it did not construct itself. NIST guidance on access control and information flow is broadly relevant here, and teams can use NIST SP 800-53 Rev 5 Security and Privacy Controls as a reference point for disciplined authorization handling. This guidance breaks down when the app must preserve third-party sharing semantics but cannot reliably distinguish trusted from attacker-controlled URIs.

Where the Pattern Changes and Why That Matters

Tighter intent handling often increases implementation overhead, because the app must distinguish legitimate sharing workflows from reflected input that only appears legitimate. That tradeoff is real when an application supports file selection, document preview, export, or cross-app editing, because those features naturally involve URIs and temporary grants.

There are a few edge cases that change the severity:

• If the app generates the URI itself and never accepts external URI values, the risk is much lower.
• If the app sanitises the intent but still forwards permission flags, the data path may remain dangerous even when the payload is partially checked.
• If the URI points outside app-private content and to intentionally shared data, the issue shifts from covert exfiltration to overbroad access control.
• Platform behaviour and OEM variations can affect how grants are propagated, so tests should confirm actual device behaviour rather than assuming consistent enforcement.

Guidance-vs-consensus note: there is broad agreement that reflecting attacker-controlled intents is unsafe, but teams vary on how aggressively to strip flags versus reject the entire message. The safest default is to reject any external intent that attempts to supply a FileProvider URI unless that workflow is explicitly designed and bounded. The pattern stops being a simple app bug when it enables access to files that were never meant to cross the app boundary.

Risk and Threat Considerations

This pattern creates a confidentiality and trust-boundary risk on the device. The core exposure is capability leakage: the app can unknowingly pass a read grant to content it controls, allowing another app to access private files through a legitimate-looking URI path.

Failure mechanism: The attacker supplies an intent that the victim app mirrors or re-emits without validating the URI source, destination, or attached flags. Because URI grants are treated as access capabilities rather than ordinary data, the reflected intent can preserve read permission and make internal content available to the attacker’s app.

Impact: Private application files, cached documents, or other FileProvider-backed content may become readable by an untrusted app on the same device. That can expose user data, business data, or sensitive operational material and can also undermine trust in any workflow that assumes the app only shares content on purpose.

Practitioner Guidance

What to prioritise: Treat any code path that copies, echoes, or forwards intents as a security boundary. The first review target is not the file provider itself but the place where external input is converted into a returned capability.

What to verify: Confirm that the app rejects unknown URI sources, strips permission flags unless a sharing flow explicitly requires them, and only returns URIs it created for that transaction. For sensitive flows, test the actual round trip with a hostile sender, not just a well-formed request from a trusted harness.

Practitioner takeaway: The decisive control is ownership of the URI grant, not the cosmetic validity of the intent payload; if the app did not create the access path, it should not be able to reissue it.

Related resources from NHI Mgmt Group

• What happens when Android screen share protections are disabled and a recording session starts before the app launches?
• What breaks when Android app security depends only on open-source protections?
• How should organisations respond if Android Keystore operations cause app slowdown?
• What breaks when Android app components are exposed without protection?