External Control of File Path

This is CWE-73, a broader and subtly different problem than classic path traversal. Path traversal (CWE-22) is about a user smuggling ../ sequences into a value that's supposed to stay within one directory. External control of file name or path is about the application letting the user choose the filename or path itself, with no traversal trickery required at all, because the parameter was designed to accept a filename as its whole value. A template-selection parameter that takes a filename directly, an export feature that lets the user name the output file, or an image-processing endpoint that writes its result to a user-supplied path are all instances: there's no ../ needed if the application already trusted the user to supply a full filename in the first place, and that trust extends further than intended, letting the user point at a file elsewhere on the filesystem, overwrite an existing file that matters, or read one that was never meant to be selectable.

• Template or theme selection parameters that take a filename directly
• Export, report-generation, or file-conversion features that let the user name the output file or choose an output directory
• Import or "load from file" features that accept a path rather than an upload

• Submit an absolute path or a filename referencing a sensitive system file where the parameter was expected to hold only a simple filename
• Submit a filename that collides with an existing application file (a configuration file, another user's upload) to test whether a write operation can overwrite it
• Combine with null-byte or extension tricks where the backend appends its own extension to a user-supplied base name, to see whether that suffix can be defeated

• /etc/passwd, /etc/hosts, or an absolute path to a known application configuration file, submitted where a bare filename was expected
• A filename matching an existing critical file the application writes to, to test for unintended overwrite

For any parameter that accepts a filename or path as its entire value, rather than being appended to a fixed base path, test whether an absolute path or a path referencing a file outside the intended directory is accepted and acted on. This is distinct from a path-traversal probe (which targets ../ sequences within an otherwise-fixed base path) and needs its own test: submit a full path directly and check whether the resulting read or write operation reflects that exact location rather than being confined to an expected directory.

Tip: Testing tools that run these checks in parallel across every discovered endpoint can cut the time required substantially compared to fully manual testing, as long as they confirm findings with more than one signal to keep the false-positive rate down.

An application that takes a filename parameter but always resolves it relative to a fixed, sanitized base directory, rejecting or stripping absolute paths and traversal sequences, is not vulnerable even though the parameter superficially "controls" a filename; the finding requires demonstrating the resolved path actually escapes the intended directory.

Manual Testing Methodology

Here is a systematic approach to identifying External Control of File Path vulnerabilities in a target application.

Before testing, map all input vectors that could be affected. Identify parameters, headers, cookies, and request bodies that interact with the vulnerable component. A proxy such as Burp Suite or OWASP ZAP, paired with normal browsing of the target, is usually enough to build this list.

Send a legitimate request and record the normal response: status code, content length, response time, and any identifying tokens. This baseline matters because it's what you'll compare later responses against once payloads are involved.

Inject test payloads into each identified input vector one at a time. Start with benign detection payloads before escalating to anything that could actually trigger the vulnerability. For External Control of File Path specifically, submit ../ sequences of increasing depth (../etc/passwd, ../../etc/passwd, and so on) alongside URL-encoded (%2e%2e%2f), double-encoded, and null-byte variants against every file-path parameter, and try both forward- and back-slash separators since one is sometimes filtered while the other isn't.

Compare the response against your baseline, looking specifically for the actual contents of a known system file (/etc/passwd, win.ini) appearing in the response, or a distinct error message (a different exception type or path echoed back) between a valid relative path and a traversal attempt.

Once a potential vulnerability is detected, confirm it with at least a few independent test cases to rule out coincidence. Document the exact request and response as proof. For External Control of File Path, a confirmed finding typically means showing that attacker-controlled input changes the application's behavior in a way that matters for security, not just that a payload was reflected somewhere harmless.

Real-World Impact

Path traversal lets attackers read, and sometimes write, files outside the directory an application intended to expose, usually by slipping ../ sequences into a file path parameter. Successful exploitation can expose source code, configuration files containing database credentials and API keys, and system files like /etc/passwd. In write scenarios, it can lead directly to code execution through a planted web shell.

In containerized environments, path traversal can escape an application's own file namespace to read secrets, environment variables, and mounted volumes belonging to other services entirely. In cloud deployments, it can expose provider-specific metadata files too.

This bug class becomes especially dangerous when combined with file inclusion. Reading a file is an information disclosure on its own, but if that file gets executed, the finding becomes remote code execution.

Prevention and Secure Coding

Preventing External Control of File Path takes a defense-in-depth approach — no single control below is sufficient alone, but together they close off both the primary path and the most common bypasses.

Canonicalize and verify containment. Resolve the requested path to its canonical absolute form and check that it still falls inside an allowlisted base directory before touching the filesystem — check this after resolving symlinks and encoded sequences, not before.

Map to an internal ID, not a raw path. Where feasible, have user input select from a server-side allowlist or database record (an internal file ID) rather than being used as any part of a filesystem path directly.

Reject traversal sequences outright. Reject requests containing ../, .., URL-encoded variants (%2e%2e%2f), and null bytes rather than trying to strip them — stripping is a common source of filter-bypass bugs when done with a single non-recursive replace.

Least-privilege filesystem access. Run the file-serving process under an account with read access to only the directories it legitimately needs, so a traversal that gets past the application-layer check still hits an OS-level permission wall.

Disable directory listing and dangerous parsers. Serve static content through a web server configuration that has autoindexing disabled and doesn't execute uploaded files as scripts.