What Is a Path Traversal Attack? Explained

A path traversal attack (also called directory traversal) manipulates a file path supplied to a web application so it resolves outside the directory the application intended to expose — often reaching sensitive files like configuration data, credentials, or source code elsewhere on the server. The classic payload is a string of ../ sequences that walk the path back up the directory tree before pointing at a target file, such as ../../../../etc/passwd.

How the attack works

Many web applications accept a filename or path as user input — think an image gallery that loads /images?file=logo.png, or a document viewer that takes a path parameter. If the application concatenates that input directly into a filesystem path without validating it, an attacker can substitute their own path:

GET /images?file=../../../../etc/passwd

If the server naively joins this with a base directory like /var/www/app/images/, the resulting path resolves outside that directory entirely, and the server happily reads and returns the requested file. The same technique using ..\ works on Windows paths.

This is a form of injection: like SQL injection and the broader class of injection flaws, the root cause is untrusted input being interpreted as part of a command or path rather than as inert data. It belongs to the OWASP Top 10’s broken access control category, since it lets an attacker reach resources they were never authorized to see.

What attackers go after

• Configuration and secrets files — .env files, database connection strings, API keys.
• Application source code — revealing business logic, other vulnerabilities, or hardcoded credentials.
• System files — password files, SSH keys, or registry hives, useful for reconnaissance or privilege escalation.
• Log files — sometimes combined with log poisoning to achieve remote code execution.

When the vulnerable endpoint also allows writing files, not just reading them, path traversal escalates from an information-disclosure bug into full remote code execution — an attacker can write a malicious script into a directory the web server executes from.

Common bypass techniques

Basic filters that just strip literal ../ substrings are easy to defeat:

• Encoding tricks — URL-encoding, double encoding, or Unicode variants that decode to ../ only after the filter has already run.
• Nested sequences — ....// becomes ../ once a naive filter strips the inner ../ and leaves the outer characters behind.
• Absolute paths — supplying an absolute path directly, which bypasses relative-path filters entirely on systems that accept them.
• Null byte injection — historically used to truncate a path after appending a fake extension, though most modern runtimes have closed this off.

This cat-and-mouse dynamic is exactly why blocklist-based defenses — banning specific strings — are unreliable, and why the fix belongs in how paths are resolved, not in pattern-matching the input.

How to prevent it

• Avoid passing user input to filesystem APIs at all. Where possible, use an indirect reference — an ID that maps to a filename server-side — instead of accepting a path or filename directly. This is the most robust fix, since there’s no path left to manipulate.
• Resolve and validate the canonical path. After building the full path, resolve it (following symlinks and .. segments) and verify the result is still inside the intended base directory before opening the file. Comparing raw strings before resolution is what lets encoding tricks slip through.
• Allowlist rather than blocklist. If a filename must come from user input, validate it against a strict allowed character set and reject anything containing path separators.
• Run with least privilege. Even if a traversal bypass gets through, a process that can only read the files it actually needs limits the blast radius — the same principle of least privilege that applies to any service account.
• Layer in a WAF. A web application firewall can catch common traversal patterns as a defense-in-depth measure, but it should never be the only control — WAF rules can be bypassed by novel encodings, same as any blocklist.

Input handling for this class of bug follows the same discipline as any other injection flaw: validate that input matches what’s expected, then sanitize or escape it for the context it’s used in. See input validation vs. sanitization vs. escaping for how those three controls differ and where each one belongs.

Path traversal vs. related flaws

Path traversal is often confused with — or chained alongside — a couple of neighboring vulnerability classes. An IDOR also lets an attacker reach resources they shouldn’t, but by manipulating an object reference like a database ID rather than a filesystem path. SSRF tricks a server into making requests to unintended destinations, which can include traversal-style tricks against internal file paths. All three share the same underlying lesson: never trust a client-supplied reference to point where the client claims it points.

The takeaway

Path traversal exploits the gap between the path a developer intended a user to request and the path the filesystem actually resolves once ../ sequences, encoding tricks, or absolute paths are thrown at it. The fix isn’t a smarter blocklist — it’s avoiding raw filesystem access from user input where possible, and when that’s unavoidable, resolving the canonical path and checking it against an allowed base directory before ever opening the file.