Category: Attack Techniques
Directory Traversal
Also known as: Path Traversal, dot-dot-slash attack
Simply put
Directory traversal is a type of cyberattack that exploits vulnerabilities in web servers and web applications to access files and directories outside the intended scope. An attacker manipulates file path references, typically using sequences like '../', to navigate beyond restricted boundaries. This can allow unauthorized access to sensitive files stored on the server.
Formal definition
Directory traversal (also known as path traversal) is a web security vulnerability in which an attacker manipulates variables or parameters that reference files or directories on the server, typically by injecting path-traversal sequences such as '../' or encoded equivalents, to escape the intended directory context. Successful exploitation enables reading of arbitrary files on the server running the application, potentially including configuration files, credentials, or other restricted resources outside the web root or application directory.
Why it matters
Directory traversal vulnerabilities allow attackers to read arbitrary files on a server, potentially exposing configuration files, credentials, application source code, and other sensitive resources that were never intended to be accessible. Because these vulnerabilities exploit the way applications handle file path references rather than requiring a flaw in authentication or authorization logic directly, they can bypass access controls entirely and expose data that would otherwise be protected by the application's permission model.
Who it's relevant to
Web Application Developers
Developers are responsible for ensuring that any application logic that accepts user-supplied input and uses it to construct file paths performs strict server-side validation. This includes canonicalizing paths before use and verifying that the resolved path falls within the intended directory, rather than relying solely on filtering traversal sequences from input.
Security Engineers and Penetration Testers
Security engineers and penetration testers need to identify directory traversal vulnerabilities during assessments by testing file path parameters with traversal sequences and encoded variants. They should be aware that static analysis tools may flag obvious string concatenation patterns but typically cannot determine at the code level whether runtime path resolution and validation are sufficient without execution context.
Application Security Program Managers
Program managers overseeing secure development lifecycles should ensure that directory traversal is included in threat models for any application that reads files based on user-supplied input. Requiring server-side input validation standards and including path traversal test cases in security testing requirements helps reduce the likelihood of this class of vulnerability reaching production.
DevSecOps and Platform Engineers
Platform and infrastructure engineers can apply defense-in-depth controls such as running web application processes with least-privilege file system permissions, so that even if a traversal vulnerability is exploited, the files accessible to the process are limited. Web application firewalls may provide some detection of common traversal patterns, though they can be bypassed by encoding variations and should not be treated as a primary control.
Inside Directory Traversal
Path Traversal Sequences
Character sequences such as '../' (dot-dot-slash) and their encoded variants that attackers use to navigate upward through directory hierarchies beyond the intended root, including URL-encoded forms like '%2e%2e%2f' and double-encoded forms like '%252e%252e%252f'.
Canonicalization
The process of resolving a file path to its absolute, normalized form before validation or access, collapsing traversal sequences and symbolic links so that the resolved path can be reliably compared against an allowed base directory.
Web Root or Allowed Base Directory
The boundary directory that an application intends to restrict file access within, such that any resolved path falling outside this boundary should be rejected as unauthorized.
User-Controlled Path Input
Application input parameters, such as query strings, form fields, headers, or API arguments, that are incorporated into file system path construction without sufficient validation, forming the attack surface for directory traversal.
Encoding and Bypass Techniques
Attacker methods that obfuscate traversal sequences through URL encoding, double encoding, Unicode normalization variants, or null byte injection to evade input filters that perform naive string matching rather than canonical path comparison.
Allowlist-Based Path Validation
A defensive control that explicitly permits only known-safe filenames or paths, evaluated after canonicalization, rather than attempting to blocklist known malicious sequences.
Chroot Jail and OS-Level Confinement
An operating system or container mechanism that restricts a process's view of the file system to a specific subtree, providing a defense-in-depth layer that limits the impact of a successful traversal even when application-level controls fail.
Common questions
Answers to the questions practitioners most commonly ask about Directory Traversal.
Does blocking '../' sequences in user input reliably prevent directory traversal attacks?
No. Blocking literal '../' sequences is insufficient as a primary defense because attackers can bypass such filters using URL encoding ('%2e%2e%2f'), double encoding ('%252e%252e%252f'), Unicode or UTF-8 variants, and OS-specific path separators. Input validation may be applied inconsistently across a request handling pipeline, meaning a filter at one layer may not account for how another layer decodes the input. The reliable defense is to resolve the canonical absolute path of any user-influenced file reference and verify that it falls within the intended base directory before opening the file.
If an application runs as a low-privilege user, does that prevent directory traversal vulnerabilities?
No, though it does reduce the potential impact. A low-privilege process account limits which files on the filesystem the application can access, so a traversal attempt may not reach sensitive system files outside that account's permissions. However, the vulnerability still exists and may still expose configuration files, application secrets, user data, or other files readable by that account. Privilege reduction is a defense-in-depth measure, not a substitute for fixing the traversal vulnerability itself.
How should an application validate file paths to prevent directory traversal?
The recommended approach is to resolve the full canonical path of the requested file using the platform's path canonicalization function (such as 'realpath()' in C or PHP, 'Path.GetFullPath()' in .NET, or 'toRealPath()' in Java) after combining the base directory with the user-supplied input. The resolved path must then be checked to confirm it begins with the expected base directory string. This check should occur after all decoding steps and before the file is opened. Allowlisting specific filenames or identifiers instead of accepting raw path input is also a strongly preferred design where feasible.
What is the difference between directory traversal and local file inclusion, and should they be treated differently in code review?
Directory traversal refers to reading arbitrary files outside an intended directory by manipulating path references. Local file inclusion (LFI) typically refers specifically to PHP and similar contexts where a user-controlled value is passed to a file inclusion function, causing the server to execute the contents of the targeted file rather than only reading it. LFI therefore carries a higher severity because it may enable remote code execution if an attacker can influence a file the server will execute. In code review, both require scrutiny of any user-influenced value that reaches a filesystem operation, but LFI review additionally requires examination of include, require, and equivalent functions.
Can static analysis tools reliably detect directory traversal vulnerabilities?
Static analysis tools can identify patterns where user-controlled data flows into filesystem operations without apparent sanitization or path validation, which covers many common traversal cases. However, static analysis has known false negative behavior in cases where sanitization is performed indirectly, through custom or framework-provided abstractions the tool does not model, or where the data flow spans multiple services or processes. False positives occur when the tool cannot determine that a sanitization step is effective. Static analysis cannot detect traversal risks that depend on deployment-time configuration, such as which directories are mounted or which user account the process runs under. Dynamic testing and manual code review complement static analysis for broader coverage.
How should directory traversal protections be tested in a web application?
Testing typically includes submitting traversal sequences in all parameters, headers, and path segments that may influence file operations, using both unencoded and encoded variants including single URL encoding, double encoding, and Unicode representations. Testers should verify whether the application returns different responses (content, error messages, or timing differences) for existing versus non-existing files outside the base directory, as such differences indicate the traversal reached the filesystem. Automated scanners can cover common encoding variants but may miss application-specific logic or unusual decoding paths. Manual testing should focus on any parameter documented or inferred to reference a filename, template, or resource path. Testing should also confirm that the canonical path check is enforced server-side and cannot be bypassed by manipulating the base directory value itself if that value is configurable.
Common misconceptions
Blocking '../' string patterns in user input is sufficient to prevent directory traversal.
Simple string-matching blocklists are routinely bypassed through URL encoding, double encoding, Unicode normalization, and other obfuscation techniques. Effective prevention requires canonicalizing the resolved path first and then verifying it starts with the intended base directory, rather than inspecting the raw input string.
Static analysis tools can reliably detect all directory traversal vulnerabilities in an application.
Static analysis can identify patterns where user-controlled input flows into file system APIs without evident sanitization, but it typically produces false positives where custom validation exists and false negatives where traversal behavior depends on runtime configuration, indirect data flows, or framework behavior that is not fully modeled at the code level.
Running an application as a low-privilege user eliminates the risk posed by directory traversal.
Reduced OS privileges limit the files that can be read or written if a traversal succeeds, but they do not prevent the traversal itself. Sensitive files readable by the application's runtime user, such as configuration files or application source code, may still be exposed, so privilege reduction is a mitigation layer rather than a complete control.
Best practices
Canonicalize all file paths using the platform's native path resolution function before performing any validation, and confirm that the resolved absolute path begins with the expected base directory before allowing file access.
Use allowlists of permitted filenames or file extensions rather than attempting to blocklist known traversal sequences, since blocklists are consistently bypassed by encoding and normalization variants.
Avoid constructing file system paths directly from user-supplied input where possible. Prefer indirect reference maps that translate user-supplied identifiers to server-side file paths, removing user input from path construction entirely.
Apply OS-level confinement such as chroot jails, containers, or mandatory access control policies to restrict the process's accessible file system to only the directories required for legitimate operation, providing a defense-in-depth layer if application controls fail.
Include directory traversal test cases, covering URL-encoded, double-encoded, and Unicode-normalized traversal sequences, in both automated scanning and manual penetration testing, since automated scanners may miss variants that require context-specific payload adjustment.
Conduct code review specifically targeting all locations where user-controlled input influences file system operations, treating such data flows as high-risk sinks that require verified canonicalization and boundary checks regardless of any upstream input handling.