What is Path Traversal?

Path traversal, also called directory traversal, occurs when untrusted input influences a filesystem path. Relative components such as ../, absolute paths, alternative separators or encoded variants can lead the resolved path outside its intended directory. The attacker thereby reaches files or directories outside the permitted area.

How does path traversal work?

A download function might concatenate /srv/reports/ with a file parameter. A value such as ../../config/app.env may resolve outside /srv/reports. Attack patterns vary by platform, framework and decoding steps. URL encoding, double encoding, backslashes, Unicode normalization and symbolic links can bypass an apparently simple filter.

Where does the vulnerability occur?

What impact is possible?

Read access can expose source code, configuration, credentials, private keys, logs or personal data. Write access is often more critical: overwriting configuration, web files, SSH keys or scheduled tasks can enable code execution and full compromise. The archive-extraction variant is often called Zip Slip. Impact is bounded by the application process's filesystem permissions, one reason not to run services as administrator.

How do path traversal and file inclusion differ?

Path traversal describes leaving an intended path area during reading or writing. Local file inclusion means the application includes a selected local file as code or a template. LFI often uses traversal, but not every traversal flaw interprets a file. A download may disclose confidential content without executing it.

How is path traversal prevented?

1. Avoid paths: Map stable external IDs to known files server-side.
2. Allowlist: Permit expected names, types and extensions only.
3. Canonicalize: Resolve the final path once and safely verify it remains beneath the expected base directory.
4. Account for races: Combine validation and access so symlinks or intervening changes cannot cross the boundary.
5. Limit rights: Use a separate service account, restrictive mounts and a read-only filesystem.
6. Name uploads safely: Generate names server-side and use safe archive libraries.

Removing ../ is insufficient: nested sequences can reappear after replacement and later decoding changes the value. The canonical destination immediately before access is what matters.

Code example: do not accept file paths from the client

Vulnerable:

$name = $request->input('file');
return response()->download(
    storage_path('app/exports/' . $name)
);

Safe design using an indirect reference:

$export = $request->user()
    ->exports()
    ->whereKey($request->route('export'))
    ->firstOrFail();

return Storage::disk('private')->download(
    $export->storage_key,
    $export->original_name
);

The client selects only an object ID. Storage key and download name come from separate server-side fields; the relationship also enforces ownership.

How is it tested?

Testers identify file-related parameters and exercise relative, absolute, encoded and platform-specific paths. Read proofs use a harmless known file; write tests need an agreed target area and safe cleanup. Error messages, response-length differences and timing provide clues but need controlled confirmation. Archives, symlinks and alternative API versions belong in the assessment as well.