Path traversal (directory traversal): how ../ works, how testers prove it, how to fix it

Path traversal, also called directory traversal, is a flaw that lets an attacker read or write files outside the folder an application meant to expose. The attacker puts path elements such as ../ into a file name or path, and the application joins them to a base folder without checking where the result lands. CWE-22 describes it as using external input to build a pathname meant to sit "underneath a restricted parent directory" without neutralizing special elements that can make it resolve elsewhere.

Testers check for path traversal in web application penetration testing and API penetration testing. Testing needs written authorization from the system owner.

What is path traversal, and is directory traversal the same thing?#

Path traversal and directory traversal are two names for one flaw. CWE-22 prefers "path traversal" and lists "directory traversal" as an alternate term. OWASP also calls it dot-dot-slash. The flaw lets a user step up out of an intended folder.

The result depends on what the application does with the path:

• Read: the attacker downloads a file the app never meant to serve, such as a configuration file.
• Write: the attacker saves or replaces a file outside the upload folder.
• Include: the app loads the file as a template or script, which is local file inclusion (LFI).
• Delete: a delete feature removes a file the user does not own.

How does a path traversal attack work?#

A path traversal attack works because the operating system resolves .. as "the parent folder." If the application appends user input to a base folder and then opens the result, enough .. elements move the final path out of that folder.

# Vulnerable: the name is joined to the folder with no check
@app.get("/download")
def download():
    name = request.args["file"]
    return send_file("/srv/fileshelf/invoices/" + name)

GET /download?file=invoice-2026-10.pdf HTTP/1.1
Host: app.example.com

GET /download?file=../marker.txt HTTP/1.1
Host: app.example.com

Which encodings and variants appear in path traversal tests?#

Applications often filter the plain ../ and then decode the input later, so testers check the encoded and nested forms that OWASP documents. This table lists the families and the weak filter each one exposes. It does not list working strings for real products.

The OWASP page on path traversal lists these encodings. The rule that covers all of them is the same: do not try to recognize bad input. Resolve the final path and compare it with the base folder.

Where does path traversal hide?#

Path traversal hides in any code path that turns a request value into a file path. Download endpoints are the obvious case. The less obvious ones are the ones testers find.

Zip Slip deserves its own note. Snyk published the Zip Slip research on 5 June 2018 and described it as an arbitrary file overwrite flaw through archive entries whose names contain ../. The flaw sits in the extraction code, so it appears even when no URL parameter is involved.

How does path traversal differ from LFI and file upload flaws?#

Path traversal chooses a file path. LFI makes the app load that file as code. A file upload flaw puts attacker-chosen content on the server. They often appear together, but each needs a different fix.

How do you fix path traversal in code?#

Fix path traversal in one of two ways. The best way is to never use the user's value as a path: map an ID to a stored path. When you must use a file name, resolve the full path and check that it is still inside the base directory.

The OWASP and PortSwigger guidance agrees on this order: avoid passing user input to file APIs, and when you cannot, validate the input and then check the canonical path begins with the expected base folder. These examples show the pattern in five stacks.

Python

from pathlib import Path

BASE = Path("/srv/fileshelf/invoices").resolve()

def open_invoice(name: str):
    target = (BASE / name).resolve()
    if not target.is_relative_to(BASE):
        raise PermissionError("outside base directory")
    return target.open("rb")

Flask's send_from_directory already does this check. Its documentation says it "uses safe_join() to ensure the path coming from the client is not maliciously crafted to point outside the specified directory."

Node.js

const path = require("node:path");
const fs = require("node:fs/promises");

const BASE = path.resolve("/srv/fileshelf/invoices");

async function readInvoice(name) {
  const target = path.resolve(BASE, name);
  if (!target.startsWith(BASE + path.sep)) throw new Error("outside base directory");
  const real = await fs.realpath(target);
  if (!real.startsWith(BASE + path.sep)) throw new Error("symlink escape");
  return fs.readFile(real);
}

Java

Path base = Paths.get("/srv/fileshelf/invoices").toRealPath();
Path target = base.resolve(name).normalize();
if (!target.startsWith(base)) {
    throw new SecurityException("outside base directory");
}
byte[] data = Files.readAllBytes(target.toRealPath());

Go

// Go 1.24 or later: os.Root refuses paths that leave the directory,
// including symlinks that point outside it.
root, err := os.OpenRoot("/srv/fileshelf/invoices")
if err != nil { return err }
defer root.Close()
f, err := root.Open(name)

The Go team's post on os.Root presents it as a simple defense against unintentional path traversal. On older Go versions, use filepath.IsLocal(name) for names that must stay relative.

PHP

$base = realpath('/srv/fileshelf/invoices');
$target = realpath($base . DIRECTORY_SEPARATOR . $name);
if ($target === false || strpos($target, $base . DIRECTORY_SEPARATOR) !== 0) {
    http_response_code(403);
    exit;
}
readfile($target);

Two cautions apply to every stack. Compare against the base path plus a separator, because /srv/fileshelf/invoices-old also starts with /srv/fileshelf/invoices. And check symlinks, because a link inside the folder can point out of it.

How do you stop Zip Slip when extracting archives?#

Check every entry's final path before writing it. Do not trust the name inside the archive. In Python 3.12 and later, the tarfile module has extraction filters. The documentation says that since Python 3.14 the default filter is data, which blocks the most dangerous issues but not every unintended or insecure behavior. For older versions, pass the filter explicitly:

with tarfile.open("upload.tar") as tar:
    tar.extractall("/srv/fileshelf/work", filter="data")

For zip files in Java, resolve each entry against the destination folder, normalize it, and reject any entry whose path does not start with the destination.

Which framework defaults help, and which calls break them?#

Frameworks help most on static file routes and least where your code builds the path itself. Flask's send_from_directory applies safe_join, as its documentation states. Go 1.24's os.Root blocks escapes at the API level. Calls that take a full path (send_file in Flask, File and Paths.get in Java, fs.readFile in Node.js, readfile in PHP) apply no check at all, so each one needs the containment check above. Read your framework's documentation for the exact behavior of its static file handler and test it.

How do penetration testers detect and prove path traversal?#

Testers prove path traversal with a differential response: a request that returns a file the app should not serve, beside controls that return something different. A 200 status is not proof, because many apps return 200 with an error page.

Our method follows OWASP WSTG-ATHZ-01. We use test-owned accounts and records, save each request and response with a timestamp, and label results as Observed.

1. Request a legitimate file and save the response as the baseline.
2. Request a planted marker file one level up. A unique string in the body is the proof.
3. Request a path that does not exist, and compare the error with the marker result.
4. Request the same path anonymously and signed in, to see whether access control also differs.
5. Try the encoded forms from the table above, one at a time, and record which layer decodes.
6. Where the scope allows, read one harmless system file, such as the host name file, and stop there.

A proof that reads real credentials or private user data is not needed and is not performed. Write tests use a test-owned file, marked as test data, and the file is removed afterward. The report records the file read, the path used and what was left untouched. If a control shows the first result was misleading, we downgrade or drop the finding.

Which real vulnerabilities were path traversal?#

Path traversal flaws have appeared in web servers and network appliances, and NVD records them under CWE-22. The dates below are NVD publication dates.

The Apache case shows why a path-normalization change needs tests: a fix for one encoding left another working.

Path traversal testing checklist#

1. List every parameter, header and route that becomes a file path, template name or archive entry.
2. Confirm scope and written authorization, and agree which files may be read.
3. Plant a marker file and record its path.
4. Capture a baseline response, a not-found response and a marker response.
5. Test plain, encoded, nested and absolute forms, one at a time.
6. Test Windows separators and drive letters where the host runs Windows.
7. Test upload file names and archive entry names for write access.
8. Compare anonymous and signed-in access to the same path.
9. Check that the app does not follow symlinks out of the base folder.
10. Retest after the fix with the same requests.

When should you get a professional test?#

Get a professional test when your application serves files by name, resizes or converts user files, extracts archives, or loads templates by a request value. Scanners find the simple file= cases. They miss second-order cases such as a stored file name used later by a batch job. Excession Labs includes path traversal checks in web application penetration testing and API penetration testing, under written authorization.

Related guides: file upload vulnerabilities, server-side request forgery and OS command injection.