Path traversal occurs when application input influences a filesystem path and the resulting path escapes the directory or object set the feature was meant to use. The input may contain parent-directory segments, absolute paths, alternate separators, or encoded forms. The underlying problem is that the application treats a user-controlled name as a trusted location.
File paths enter through ordinary features
Download routes, uploads, archive extraction, document previews, template selection, log viewers, import tools, and backup functions all work with names that may become paths. Cloud object keys and virtual filesystems can have similar boundary problems even when no local disk is exposed.
An audit of vibe-coded software finds each path-building operation across the attack surface. Generated code may normalize an upload name in one handler but join an untrusted name directly in a preview or cleanup job.
| Feature | Untrusted value | Boundary to verify |
|---|---|---|
| Download | File name or record key | Approved storage root |
| Upload | Original name and destination | Generated server-side location |
| Archive extraction | Entry names inside archive | Extraction directory |
| Template or report | Selected template name | Fixed allow-list |
| Cleanup job | Stored path or object key | Tenant and storage scope |
Normalization alone is not authorization
Path normalization resolves separators and relative segments into a consistent form. The application must then verify that the resolved result remains inside the approved root. Checking a raw string before decoding or normalization can miss an equivalent path representation.
Input validation should constrain file identifiers to the format the feature needs. A safer design keeps user-facing identifiers separate from storage paths and resolves them through application-owned metadata. Authorization remains necessary as well: a path can stay inside the storage root while still pointing to another customer's file.
What the audit checks
The review follows file and object references from input to operation:
- Locate path construction: Find joins, resolves, archive libraries, storage clients, and file APIs.
- Identify controlled segments: Record every name, key, prefix, and destination influenced by external data.
- Normalize once: Determine when decoding and canonical path resolution occur.
- Enforce containment: Verify the final path against the intended root or approved object set.
- Check the operation: Consider reads, writes, moves, deletes, extraction, and execution separately.
Evidence includes side effects
Tests should cover alternate separators, encoded segments, absolute paths, nested archives, and valid names near the boundary. The expected outcome is a controlled rejection with no partial file creation, overwrite, disclosure, or cleanup outside the permitted scope.
The runtime identity also matters. Restrictive filesystem and storage permissions limit the effect of a missed application check. They do not replace containment, but they reduce the set of files the process can reach. An audit records both layers so that production software generated quickly does not rely on a single string check for a storage boundary.
