How do you prevent path traversal in Java when building a file path from user-supplied input?

## The vulnerability: path traversal (a.k.a. directory traversal) Many apps build a filesystem path from user input — a download endpoint, an upload name, a template loader. **Path traversal** is when an attacker supplies special path components so the resolved path points *outside* the directory you meant to confine them to, letting them read or overwrite arbitrary files. The key tool is the **relative path component `..`** ("parent directory"). Given: ```java File f = new File("/srv/uploads/" + name); // name from the user ``` if `name` is `../../etc/passwd`, the resulting path resolves to `/etc/passwd`. Variants include absolute paths (`/etc/passwd`), URL-encoded dots (`%2e%2e%2f`), Windows separators (`..\\`), and **symlinks** that point elsewhere. This is, again, a **trust-boundary** failure: untrusted text is used to address a resource without confirming it stays inside the allowed region. ## Why naive checks fail - **Blacklisting `..`** is fragile: encodings (`%2e%2e`), mixed separators, and overlong forms slip through; and an absolute input doesn't even need `..`. - **String-prefix checking the *raw* input** is wrong because the raw string isn't the real location: `.`/`..` haven't been collapsed and **symlinks** haven't been resolved. A path that *textually* starts with your base can still resolve elsewhere via a symlink. ## The fix: canonicalize, then check containment The robust pattern has two steps: 1. **Canonicalize** the candidate path to its single, absolute, real form — resolving `.`, `..`, and symlinks. 2. **Verify containment**: the canonical target must be *inside* your canonical base directory. **NIO (preferred):** ```java Path base = Paths.get("/srv/uploads").toRealPath(); // real, absolute base Path target = base.resolve(userName).normalize(); // join + collapse .. if (!target.startsWith(base)) { // containment check throw new SecurityException("path traversal blocked"); } // optional: target = target.toRealPath(); // also resolve symlinks of the target ``` - `resolve` joins the user name onto the base (and conveniently, if `userName` is *absolute*, `resolve` returns it as-is — which is exactly why the containment check afterward is essential). - `normalize()` collapses `..`/`.` lexically. - `startsWith(base)` is a **path-component** comparison (not a string prefix), so `/srv/uploads-evil` does not count as inside `/srv/uploads`. - `toRealPath()` additionally resolves symlinks (it requires the file to exist); use it on the target when you must defeat symlink tricks. **Legacy java.io:** ```java File base = new File("/srv/uploads").getCanonicalFile(); File target = new File(base, userName).getCanonicalFile(); if (!target.toPath().startsWith(base.toPath())) { throw new SecurityException("path traversal blocked"); } ``` `getCanonicalPath()/getCanonicalFile()` resolve `..`, `.`, and symlinks to an absolute path (and can throw `IOException`). Compare the **canonical** target against the **canonical** base — never the raw strings. ## Hardening / defense in depth - **Reject absolute inputs and null bytes** up front; reject empty names. - **Prefer indirection:** store uploads under server-generated names (a UUID) and map a public id → real file, so the user never controls the path at all. This is the strongest option. - **Allow-list** when the set of files is known (e.g. a fixed list of report templates). - **Least privilege:** the process should only have filesystem rights to the intended directory, so even a bypass is contained. On modern JDKs the old SecurityManager is deprecated/removed, so rely on OS-level confinement (containers, file permissions). ## The general principle Validate a resource reference by **resolving it to its real identity and proving it lies within an explicit allowed region** — don't try to recognize "bad" inputs by pattern. Same spirit as binding parameters for SQL and argument vectors for commands: control the channel, don't chase the payload.