Security engineers reviewing a vulnerability scan report often pause at two terms that appear almost interchangeably: path traversal and directory traversal. Understanding the difference between path traversal and directory traversal matters more than it seems, because the wording shapes how a finding gets triaged, who fixes it, and whether the fix actually closes the hole.
The short version: directory traversal is a subset of path traversal. Every directory traversal issue is a path traversal issue, but not every path traversal issue involves directories. Once that clicks, a lot of confusing scanner output starts making sense.
What path traversal actually covers
Path traversal is the broader category. It describes any vulnerability where an attacker manipulates a file path supplied to an application in order to access resources outside the intended scope. That includes reading files, but it also includes writing files, executing files, or referencing files in ways the developer never anticipated.
A classic example: an image-resizing endpoint that accepts a filename parameter and passes it straight into a file-read function. An attacker submits something like ../../../../etc/passwd instead of a legitimate filename, and if there’s no validation, the server happily reads whatever the path resolves to.
Path traversal also shows up in less obvious places:
– Log file viewers that accept a “log name” parameter
– Template engines that load templates by name from user input
– Backup or export features that let a user specify an output path
– File upload handlers that use attacker-supplied filenames when saving to disk
That last one is worth flagging separately, since insecure filename handling during uploads is a very common entry point – see how to secure your website’s file upload functionality for the mechanics of locking that down.
Where directory traversal fits in
Directory traversal is the more specific, more commonly discussed variant: manipulating directory references (../ sequences, absolute paths, encoded variants like %2e%2e%2f) to move outside a restricted directory structure and reach files the application shouldn’t expose.
When someone says “directory traversal,” they almost always mean the classic dot-dot-slash attack against a file system hierarchy. It’s the scenario security training decks use as the canonical example, and it’s the one most WAF rules are tuned to catch first.
In practice, the terms get used loosely enough that treating them as synonyms causes no real harm day to day. The distinction matters mainly in two situations: when writing precise vulnerability reports, and when deciding whether a fix that blocks “../” sequences is actually sufficient coverage for the broader path traversal risk.
A common misconception worth busting
A surprisingly persistent myth is that stripping “../” from user input solves path traversal entirely. It doesn’t, and this is one of the more frequent mistakes seen in code review.
Attackers have several ways around naive dot-dot-slash filtering:
– Double encoding: %252e%252e%252f, which some decoders unwrap twice
– Unicode or overlong UTF-8 encoding of the same characters
– Absolute paths that don’t use ../ at all, like /etc/passwd or C:Windowssystem32
– Null byte injection to truncate a path after an appended extension (older PHP versions were notorious for this)
– Symlink abuse, where a traversal isn’t even needed because a linked file already sits outside the intended directory
A regex that blocks the literal string “../” gives a false sense of security. The reliable fix is canonicalizing the resolved path and then verifying it still sits inside the allowed base directory – not blacklisting patterns in the raw input.
How to fix it properly
The remediation approach is the same regardless of whether a finding gets labeled path traversal or directory traversal:
1. Never build file paths directly from user input. Use an allowlist of valid filenames or IDs, and map those to actual file locations server-side.
2. If a path must be built dynamically, resolve it to its canonical absolute form (resolving all ../ and symlinks) and confirm the result is still within the intended root directory before touching the file system.
3. Run the application process with the minimum file system permissions it needs – if the web server user can’t read /etc/passwd, a traversal bug becomes far less damaging.
4. Apply the same discipline to write operations. A path traversal bug that lets an attacker write a file to an arbitrary location (say, dropping a web shell into a directory the server executes) is typically more severe than a read-only version.
5. Log and alert on traversal attempts, since repeated ../ patterns in request logs are a strong signal of active reconnaissance.
This category sits inside the broader security misconfiguration and input validation buckets that automated scans check for as part of standard OWASP coverage – see how automated scans cover 70% of OWASP categories for how these checks map to the wider testing picture.
Why the distinction matters for triage
When a scan report flags “path traversal” rather than “directory traversal,” it’s often signaling that the issue isn’t a simple file-read case. It might involve a template injection angle, an object reference that happens to resolve to a file path, or an API parameter that gets passed to a shell command rather than a file system call. Treating every finding as identical dot-dot-slash abuse risks under-scoping the fix.
Conversely, if a report specifically says directory traversal, the fix is usually narrower: validate and canonicalize the path, confirm it stays within bounds, and move on. Reviewing findings with this distinction in mind saves time during remediation planning and helps prioritize the write-capable cases, which tend to be far more dangerous than read-only exposure.
Frequently asked questions
Is path traversal the same as local file inclusion (LFI)?
They’re related but not identical. LFI specifically refers to including a file’s contents into program execution, such as a PHP include() call, which can lead to code execution. Path traversal is the underlying technique that often enables LFI, but path traversal can also result in simple information disclosure without any code execution involved.
Can path traversal happen without any “../” in the request?
Yes. Absolute paths, symlink tricks, and encoded variants can all achieve the same result without a literal dot-dot-slash sequence appearing in the raw request, which is exactly why pattern-based filtering fails so often.
Does HTTPS or a web application firewall prevent path traversal?
No. Encryption in transit has nothing to do with how an application validates file paths server-side, and WAF rules only catch known patterns – encoded or unusual payloads regularly slip through. The actual fix has to happen in the application logic.
Whether a finding is labeled path traversal or directory traversal, the underlying lesson is the same: never trust user input to determine a file system location, and always validate the resolved path rather than the raw string. Getting that one habit right closes off one of the oldest and still most exploited categories of web vulnerabilities.