External control of file name or path is a weakness where attacker-controlled input determines which file a program opens, creates, or modifies. That can expose data, overwrite system files, or enable traversal attacks, so defenders should whitelist directories, canonicalise paths, and reject path separators and absolute references from untrusted input.
What this weakness means
External control of file name or path occurs when untrusted input decides which file a program opens, creates, or modifies. The core problem is not just bad input validation, but allowing user influence over a filesystem location that should be reserved for the application or operating system.
That makes the weakness especially dangerous in any workflow that builds paths from request parameters, filenames, upload metadata, archive contents, or form fields. If the application does not constrain the target location, the result can be unexpected reads, writes, deletes, or overwrites outside the intended directory.
Why it becomes a security issue
This weakness is often exploited through path traversal, absolute-path injection, or crafted names that escape a sandboxed directory. The impact can range from disclosure of sensitive files to corruption of application state, log poisoning, configuration tampering, or code execution when a writable target is abused.
It is also dangerous because the vulnerable operation may look routine. File handling is often spread across upload handlers, import routines, cache management, temporary file creation, and document processing, so the flaw can hide inside otherwise normal business logic.
How defenders constrain file handling
The safest approach is to treat the user input as a label, not as a filesystem directive. Defenders should map allowed names to known-safe locations, canonicalise paths before use, and reject path separators, absolute references, and other constructs that can redirect access outside the intended directory.
Controls for file-path safety fit naturally with broader application hardening. The application should run with the minimum filesystem privileges it needs, and sensitive directories should not be writable by the same process that handles untrusted input. OWASP API Security Top 10 is a useful adjacent reference when the file operation is exposed through an API surface and access decisions need to be tightened at the request boundary.
Detection and review after exploitation
Detection usually starts with abnormal file access patterns, unexpected locations in logs, or writes to filenames that contain traversal sequences, mixed separators, or encoded variants. Because exploitation can be subtle, teams should review recent file operations after a suspected incident, not just rely on failed request logs.
If the weakness was used to alter application files, configuration, scripts, or stored data, the compromise review should extend beyond the original entry point. A MITRE ATT&CK Enterprise Matrix view helps teams think about follow-on activity such as persistence, privilege abuse, and lateral movement after the initial file write.
Risk and Threat Considerations
This weakness matters because file access often sits on a direct trust boundary between user input and operating-system resources. When attackers can steer a path, they may be able to steal secrets, overwrite executable or configuration files, or place malicious content where the application later consumes it.
Failure mechanism: The application accepts a filename or path from untrusted input, then uses it without strict canonicalisation and allowlisting, so the attacker escapes the intended directory or targets a sensitive file.
Impact: The result can be data exposure, destructive overwrite, integrity loss, service disruption, or, in some designs, a path to code execution or durable compromise.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while 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 | V5 — File Handling | This term is a file-handling weakness centered on safe path use. |
| Recommendation — Verify file operations restrict names to approved locations and block traversal inputs. | ||
| OWASP API Security Top 10 | API8 — Security Misconfiguration | Exposed file-path handling often fails through unsafe request-bound configuration and routing. |
| Recommendation — Harden request handling so path-derived file operations cannot escape intended boundaries. | ||
| CIS Controls v8 | CIS-16 — Application Software Security | Application code that accepts file paths needs secure design and validation controls. |
| Recommendation — Review application file-handling logic for path validation and unsafe filesystem access. | ||
| NIST SP 800-53 Rev 5 | SI-10 — Information Input Validation | Untrusted path input must be validated before it drives filesystem actions. |
| AC-6 — Least Privilege | Limited filesystem privilege reduces the damage from path-control abuse. | |
| Recommendation — Validate and constrain path input before any file open, create, or modify operation. Limit the process so a bad path cannot reach sensitive or writable system files. | ||