---
{
  "title": "Path traversal",
  "summary": "Constrain file selection to authorized objects and resolved storage boundaries, accounting for normalization, symbolic links, and independent ownership checks.",
  "topic": "offensive",
  "level": "Intermediate",
  "updated": "2026-10-12",
  "published": "2026-10-04",
  "units": [
    7
  ],
  "aliases": [],
  "sources": [
    {
      "title": "OWASP: File Upload",
      "url": "https://cheatsheetseries.owasp.org/cheatsheets/File_Upload_Cheat_Sheet.html"
    },
    {
      "title": "OWASP: Path Traversal",
      "url": "https://owasp.org/www-community/attacks/Path_Traversal"
    }
  ],
  "editorialVersion": 2
}
---
## What it means

Path traversal occurs when untrusted path components let a caller escape an intended directory or access an unintended file. Encodings, separators, symbolic links, and platform differences can complicate simplistic checks. Prefer references to approved files rather than accepting arbitrary filesystem paths.

## A practical example

A document endpoint receives an internal document ID and retrieves its mapped storage object. It does not concatenate a submitted filename into a local directory path. The caller's permission to read that document is checked independently.

## What to check

Constrain file selection to authorized objects. When paths are unavoidable, verify the resolved destination against the intended storage boundary and consider race conditions and symbolic-link behavior.

## A common pitfall

Removing a single parent-directory sequence is a brittle defense. Different normalization steps or encodings can change how the final filesystem interprets the path.

## Think it through

Is a path inside the intended directory automatically authorized?

**Answer:** No. Directory containment prevents one class of escape, but the caller still needs permission for the chosen file.

## A filename is not a permission decision

Imagine a fictional academy lets learners download handouts. Accepting an arbitrary filesystem path gives the caller influence over storage selection. An internal document identifier mapped to an approved object can provide a clearer boundary, while the application checks the caller's right to that document.

Directory containment and authorization remain distinct. A file can be inside the approved storage area and still belong to another learner or course.

## Normalization changes interpretation

Suppose different components decode or normalize a path at different stages. A simple string check early in the request may not describe the destination ultimately opened by the filesystem. Platform separators, symbolic links, and race conditions can further affect the result.

When paths are unavoidable, use suitable platform APIs and a reviewed design that validates the actual intended boundary. Avoid presenting the removal of one suspicious substring as a complete solution.

## Storage design can reduce complexity

A service account limited to necessary storage reduces exposure beyond the application's own checks. Separating uploaded content from application code also helps prevent file access from becoming unintended execution or configuration modification.

For an authorized exercise, create a disposable directory containing public sample handouts and a separate private area. Describe an ID-based lookup and its resource permission check without using real sensitive files. Add a symbolic-link case to the design review and explain why the final resolved destination matters. Then verify that an allowed handout works while a denied object remains unavailable. The exercise evaluates selection, containment, account permissions, and ownership as separate parts of a defensible file-access workflow.

## Related concepts

- [[linux-filesystem]]
- [[file-upload-security]]
- [[authorization]]