What Is Path Traversal and How Does It Work?
Author: Domeny.ForSale editorial team Published
In brief: Path Traversal is a security vulnerability that lets an application access files outside the directory intended for handling a given request. It is most often associated with reading files without authorization, but functions that write or delete files may also allow those files to be changed or removed. The problem arises when an application treats user input as part of a file path without effectively checking where that path leads.
What it means to escape a directory
A path is a file’s address in the file system, for example /srv/app/documents/instructions.pdf. An application that serves documents should allow downloads only from a designated location, not from anywhere on the server.
Path Traversal, also called directory traversal or dot-dot-slash, involves crossing that boundary. The name dot-dot-slash refers to ../: the two dots represent the parent directory, and the slash separates path components. Used in a particular way, this sequence can direct an operation outside the permitted folder.
Think of a document collection counter. A customer should provide a document number, and the employee should retrieve it from the correct cabinet. The error occurs when, instead of a number, the employee accepts an instruction: “Leave this cabinet, go to the next room and fetch the specified file.”
Example: downloading a document by name
Suppose an application stores public documents in /srv/app/documents/. The user selects a file, and the browser sends a request:
/download?file=instructions.pdf
If the program appends the value of the file parameter to the document directory without checking it, the resulting path is /srv/app/documents/instructions.pdf. With an ordinary filename, this looks correct. The problem becomes apparent when the supplied value includes a reference to the parent directory:
/download?file=../konfiguracja.env
The combined path /srv/app/documents/../konfiguracja.env points to /srv/app/konfiguracja.env, a file outside the document directory. If the application can read it and returns its contents, data is exposed.
This illustrates the mechanism, not a guaranteed successful attack. The file must exist, the application process must have access to it, and the way the request is handled must allow the supplied path to be used. Test this behavior only in your own environment or with explicit permission to conduct testing.
What damage can Path Traversal cause?
The impact depends primarily on the operation performed by the vulnerable function and the permissions the application has in the operating system.
- Reading files: a download function may expose configuration, user data, backups or access credentials.
- Writing and overwriting: a vulnerable write operation may place a file outside the intended directory or modify an existing file.
- Deleting: a file deletion function may remove resources that the user should not be able to target.
Under particular conditions, overwriting configuration or placing a file that the server executes may lead to further compromise of the application. However, Path Traversal does not automatically mean that an attacker can execute code or gain full access to the server. Its scope is limited by factors including the process’s permissions and the functions the application provides.
The vulnerability is not limited to addresses visible in the browser. Data that influences a path may also come from a form, an API request, an uploaded filename or an entry in an archive being extracted.
How to reduce the risk effectively
The safest approach is to avoid letting users specify paths. Instead of accepting a filename or location, the application can accept a document identifier, such as 482, and locate the associated file itself. It must still check whether the user is authorized to download that file—an identifier alone provides no protection.
If accepting paths is necessary, protection should include several measures:
- Strictly defined input. If a function needs only a filename, it should not accept an entire path. Limit permitted names and extensions to what is actually needed.
- Checking the final location. After accounting for file system rules, the application should confirm that the target is still inside the permitted directory. Use appropriate path-handling functions rather than simply comparing string prefixes.
- Accounting for symbolic links. A symbolic link points to another location in the file system. Through such a link, a file that appears to be inside the permitted folder may lead outside it.
- Minimum permissions. The process serving documents should not have access to data it does not need, or write permissions where read access is sufficient.
Simply removing the ../ sequence is not sufficient protection. Differences in separators, encoding and processing order can cause a filter and the file system to interpret the same value differently. Validation must reflect how the application actually opens the file.
Where to start checking an application
Review the functions that download, upload, delete and extract files. For each one, determine whether the user can influence the path, which directory is permitted, and whether the program checks the operation’s final target. Tests should cover both attempts to escape the directory and ordinary, valid requests.
If you suspect that the vulnerability has been exploited, fixing the code alone may not be enough. Assess which files were accessible, check the logs and—if access credentials may have leaked—replace the relevant passwords or keys. The first practical step is to identify the exact point where user input becomes a file path.
See also: What Is Apache?
Read also
