Path traversal — also called directory traversal — lets an attacker read files outside your web application's intended directory. By injecting sequences like ../ into URL parameters or file path references, attackers navigate up the directory tree and access /etc/passwd, database credentials, private keys, and source code with no authentication required. It is classified under OWASP A03:2021 — Injection and consistently ranks among the top 10 most exploited vulnerability types in production applications each year.
How Path Traversal Works
Web applications often accept user input to determine which file to load. A URL like https://example.com/view?page=invoice.pdf looks harmless. But if the server constructs the file path by concatenating a base directory with the user-supplied parameter — something like base_dir + request.args["page"] — an attacker can request page=../../../../etc/passwd and read the system password file. The root cause is always the same: user input flows into a file system operation without sufficient validation or canonicalization.
Common Path Traversal Variants
Simple input filters that block ../ are frequently bypassed using encoding tricks. Attackers use all of the following variants in real-world exploitation:
- Classic dot-dot-slash:
../../../etc/passwd - URL-encoded slash:
..%2F..%2F..%2Fetc%2Fpasswd - Double URL-encoded:
..%252F..%252Fetc%252Fpasswd - Unicode overlong encoding:
..%c0%af,..%ef%bc%8f - Mixed encoding:
....//....//etc/passwd - Null byte injection (legacy PHP):
../etc/passwd%00.jpg - Windows path separator:
..\..\..\windows\system32\drivers\etc\hosts
Web application firewalls that only block the canonical ../ pattern will miss most of these variants. Effective detection must test all encoding combinations against every parameter.
High-Value Files Attackers Target
On Linux and Unix servers, the most common traversal targets are:
/etc/passwd— user account list, useful for username enumeration/etc/shadow— password hashes (accessible only if the process runs as root)/proc/self/environ— environment variables that often contain API keys and database passwords.env,config.php,settings.py— application configuration files in the project root/var/log/apache2/access.log— web server logs (sometimes chained into log poisoning for RCE)
On Windows servers, targets include web.config and C:\Windows\System32\drivers\etc\hosts. Any file readable by the web server process is a potential traversal target.
Real-World Impact
In 2021, a path traversal vulnerability in a managed file transfer product was exploited against hundreds of organizations before a patch was available. In 2023, a similar flaw in MOVEit Transfer triggered one of the largest data theft campaigns of the year, affecting thousands of companies across multiple sectors. Path traversal is not theoretical — it is reliably discovered and exploited in production applications at scale, and a single vulnerable parameter can expose an entire server's readable file system.
How Shieldome Detects This
Shieldome tests for path traversal automatically on every scan, injecting patterns into all discovered URL parameters and path segments. Specifically, Shieldome:
- Sends requests using 12+ distinct traversal patterns — including classic
../etc/passwd, URL-encoded variants (..%2F..%2F), double-encoded (..%252F), and mixed-encoding sequences like....//....//— targeting every URL parameter discovered during the scan - Analyzes HTTP response bodies for indicators of file system exposure: the Unix passwd format string
root:x:0:0, Windows system file markers, absolute server paths appearing in error messages, and PHP warning strings revealing internal directory structure - Detects confirmed exposure regardless of HTTP status code — many misconfigured applications return file contents with a 200 OK response, which scanners checking only for error codes will miss entirely
- Tests both query string parameters and URL path segments, since many frameworks pass path components directly into file-loading functions
Shieldome reports confirmed file content exposure as Critical under OWASP A03. Findings where error messages reveal internal paths without confirmed file content are reported as High.
How to Prevent Path Traversal
1. Never concatenate user input with file paths
The simplest fix is architectural: never use user-supplied strings as file names or path components. Map user-provided identifiers to internal file paths using a database or configuration layer that the user cannot directly influence. A request for file_id=42 that maps to a server-side database record is unexploitable via traversal.
2. Canonicalize and validate the resolved path
If you must accept file names from users, resolve the full canonical path before using it, then verify the result starts with your allowed base directory. In Python: os.path.realpath(). In Java: File.getCanonicalPath(). In PHP: realpath(). Reject any path that does not begin with the expected base directory prefix.
3. Use an allowlist of permitted file names
If only a finite set of files can ever be requested, maintain an explicit allowlist and reject anything not on it. This eliminates the traversal attack surface entirely for those endpoints — no path manipulation can succeed if only pre-approved names are accepted.
4. Run the web process with least-privilege file permissions
Even when traversal is achieved, it is far less damaging if the web server process cannot read files outside the web root. Dedicated service accounts with minimal filesystem permissions are a critical defense-in-depth layer that limits the blast radius of any traversal vulnerability.
5. Add a Web Application Firewall as a secondary layer
A WAF can block many traversal patterns at the perimeter and meaningfully raises the cost of exploitation. It is not a substitute for secure coding — sophisticated encoding can bypass signatures — but it provides an additional barrier while permanent fixes are deployed.
Frequently Asked Questions
What is the difference between path traversal and local file inclusion (LFI)?
Path traversal reads arbitrary files by navigating the directory tree. Local file inclusion (LFI) is a PHP-specific variant where the traversal causes the server to execute the included file as PHP code — not merely read it. LFI can lead to remote code execution, making it significantly more severe than a simple file read vulnerability.
Does HTTPS protect against path traversal?
No. HTTPS encrypts the transport channel but has no effect on how the server processes request parameters. Path traversal is a server-side logic flaw that exists regardless of whether the connection uses TLS. Encrypting a malicious request does not neutralize it.
Can a WAF fully block path traversal attacks?
Not reliably. Attackers use dozens of encoding variations specifically designed to evade WAF signature rules. A WAF significantly reduces risk but cannot replace proper input validation and secure file path handling in application code. Treat WAF as one layer of defense, not the only layer.
Which URL parameters are most commonly vulnerable?
Parameters named file, path, page, document, template, include, dir, and load are the highest-risk targets because they semantically suggest file system operations. Any parameter that changes which content is loaded on a page should be tested for traversal.
Is path traversal in the OWASP Top 10?
Yes. Path traversal is classified under A03:2021 — Injection in the current OWASP Top 10. Earlier OWASP editions listed it as a standalone entry; the 2021 update consolidated injection types into one category, reflecting their shared root cause of unvalidated user input reaching an interpreter.
What CVSS score does a path traversal vulnerability receive?
Confirmed path traversal vulnerabilities typically receive CVSS 3.x scores between 7.5 (High) and 9.8 (Critical), depending on which files are accessible and the privileges of the web process. Any confirmed read of sensitive files outside the web root should be treated as Critical priority regardless of CVSS score.
Can REST APIs be vulnerable to path traversal, not just web pages?
Yes. REST APIs that accept file names or paths in JSON request bodies, URL segments, or HTTP headers are equally vulnerable. Path traversal is a server-side logic flaw, not a browser-side issue, so any server-side code that passes user input to file system operations is at risk — regardless of whether it serves HTML, JSON, or binary data.
Scan your application for path traversal and 40+ other security vulnerabilities with Shieldome. Create a free account and run your first scan in under two minutes.