Teams should never trust the filename supplied by another app. The safer pattern is to ignore external name metadata, create a random local filename inside a controlled cache directory, and write only within that boundary. This reduces the impact of malicious Intents and prevents path traversal through attacker controlled display names or content provider responses.
Why Android file handoff needs defensive naming and storage boundaries
When one Android app receives a file from another app, the security question is not whether the filename looks sensible, but whether the receiving app is treating untrusted metadata as trusted input. Android Intents, content providers, and share flows can all carry display names that are convenient for users but unsafe for filesystem decisions. The receiving app should treat the transfer as data ingress, not as an instruction to mirror the sender’s naming or path choices. OWASP’s OWASP Non-Human Identity Top 10 is relevant here because the same trust-boundary discipline applies when software accepts identity-bearing metadata from another component. In practice, many teams only discover the weakness after a crafted share path or unexpected content-provider response has already influenced where the file was written.
How safe file receipt works in practice on Android
The practical control is to separate metadata from storage decisions. The sender may provide a filename, but the receiver should use that value only, at most, for display after sanitisation. The actual on-disk object should be created under a receiver-controlled cache or staging directory using a locally generated random name, because the storage location is part of the trust boundary. That prevents attacker-controlled values from steering writes into unintended paths, overwriting existing files, or creating confusion between logical identity and physical storage.
Teams should also constrain what they accept from the source app. If the file arrives through a content URI, the app should read the content stream, validate the MIME type and size where relevant, and ignore any path-like claims embedded in metadata. If the app needs to persist the file beyond temporary processing, it should promote the file only after validation, renaming it according to local policy rather than copying the original display name into a filesystem path. This is especially important when the app later passes the file to another subsystem, because unsafe names can become latent inputs in logging, indexing, archive creation, or downstream export.
- Use a receiver-owned cache directory for the first write.
- Generate a random local filename rather than reusing sender metadata.
- Treat display names as untrusted labels, not storage instructions.
- Validate type, size, and expected content before any promotion step.
Where teams often go wrong is assuming that content-provider access alone makes the input trustworthy; that assumption breaks down when the file name or storage target is still influenced by the sender.
When Android file sharing edge cases change the answer
Tighter file-handling rules often increase implementation friction, requiring teams to balance safer isolation against the convenience of preserving user-facing filenames. That tradeoff matters most when workflows depend on recognisable names for audit trails, collaboration, or later retrieval. The safer pattern is to keep an internal immutable identifier for storage and, if needed, retain the original display name only as descriptive metadata outside the path itself.
There are also edge cases where the standard pattern needs extra care. If the file may be opened by other apps, the team should assume the filename could be reinterpreted by downstream components with different parsing rules. If the file is part of a longer workflow, the receiving app should re-check the trust boundary at each handoff rather than assuming that one safe import makes every later use safe. Guidance-vs-consensus note: there is broad agreement on ignoring external path data, but teams still differ on whether original names should be preserved in metadata, logs, or user-visible exports, so that decision should be made explicitly.
In regulated or high-integrity environments, the most conservative choice is to preserve only what is operationally necessary and to discard the rest of the sender-supplied naming context. That reduces ambiguity, but it also means users may need a separate retrieval or audit mechanism if human-readable filenames are important.
Risk and Threat Considerations
Receiving files from another Android app creates a classic untrusted-input risk: a sender can supply metadata that the receiver later uses as if it were locally trustworthy. The main exposure is path traversal, unintended overwrite, or storage confusion when filename data is concatenated into filesystem logic instead of being treated as display-only information.
Failure mechanism: the attack succeeds when the receiving app copies sender-controlled names or URI-derived paths into write operations, especially before normalisation and boundary checks. That can let malicious Intents, content providers, or crafted share payloads steer the file outside the intended cache area or into a conflicting name inside it.
Impact: the receiver may overwrite important local data, write outside its intended directory, or propagate a poisoned filename into later processing steps such as archiving, logging, export, or secondary sharing.
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 address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Secrets and Credential Management | External app metadata is an untrusted identity-bearing input. |
| Recommendation — Treat sender-supplied filenames as untrusted input and keep them out of storage paths. | ||
| CIS Controls v8 | 3 — Data Protection | The issue is preventing unsafe writes and preserving controlled file boundaries. |
| 8 — Audit Log Management | Unsafe filenames can poison logs, exports, and later processing. | |
| Recommendation — Constrain file writes to a controlled directory and validate inputs before persistence. Log only sanitised metadata and preserve the original value separately if needed. | ||
| NIST CSF 2.0 | PR.AC-3 — Least Privilege | Receiver-controlled storage limits what untrusted apps can influence. |
| PR.DS-1 — Data-at-Rest Protection | Temporary storage and controlled persistence reduce exposure from untrusted files. | |
| Recommendation — Restrict imported files to the minimum storage scope required for processing. Store imported files in a controlled location and promote them only after validation. | ||
Practitioner Guidance
What to verify: verify that the first write always lands in a receiver-controlled temporary location and that the sender’s filename never participates in path construction. The check should be explicit in code review, because this failure often survives functional testing when benign filenames are used.
Common mistake: do not preserve the external filename by default just because it improves usability. If the business need is only for user recognition, keep that value as metadata and keep storage naming separate.
Practitioner takeaway: the safest Android file-receipt design treats every sender-supplied name as untrusted decoration, because once naming is allowed to influence storage, the file boundary is no longer under the receiver’s control.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 8, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
