Path traversal
In application security, path traversal is a flaw where user input is used to build a file path and the attacker escapes the intended directory, reaching files the application never meant to serve. It is also called directory traversal, and it reads or writes files with the privileges of the service.
How it works
The application joins a base directory with a name taken from the request and opens the result. Because the operating system resolves relative segments, a name containing parent directory references walks upward out of the base directory before the file is opened. Absolute paths do the same in one step where the application does not force the base.
The distinction that matters is between validating and canonicalising. Validating inspects the string the user sent. Canonicalising resolves the string to the single real path it denotes, following relative segments, symbolic links and encoding, and only then compares it. A check that runs before resolution is checking a string that the file system has not agreed to yet, which is why the correct order is resolve first, then verify that the resolved path still starts inside the base directory, then open it.
What goes wrong
Filters run in the wrong order and strip in the wrong way. Removing the parent directory sequence once leaves a payload that reconstitutes itself when the removal is applied to overlapping text. Decoding after validating lets an encoded separator through. Normalising Unicode after the check does the same. Allowing a symbolic link inside an otherwise correct base directory hands over the whole file system.
Write is worse than read and is often forgotten. An archive extractor that trusts the paths inside the archive will place files wherever the archive says, which turns an upload feature into arbitrary file write and frequently into remote code execution. In devices this class is endemic: web interfaces that serve configuration and log files by name are a standard finding in firmware analysis, and mobile applications repeat it against local storage.
Where this shows up in an audit
We test every parameter that ends up as part of a path, including headers and archive entries, and we prove it with a file whose contents cannot be mistaken for anything else. The report names the parameter, the payload, the file retrieved or written, and the account the service runs under, because that account decides whether the impact stops at configuration or reaches credentials. We also check whether read and write share the same handler, since fixing one and leaving the other is the usual partial remediation. This is part of how we test file handling in a web application.