How do you verify with pathlib that a user-supplied path stays inside a base directory?

## The two-step shape of the check Every correct containment check has the same structure: **canonicalize, then compare**, and it compares the thing you are about to open rather than the thing the user sent. ```python from pathlib import Path BASE = Path('/srv/uploads').resolve() def safe_path(user_name: str) -> Path: candidate = (BASE / user_name).resolve() if not candidate.is_relative_to(BASE): raise ValueError('path escapes the base directory') return candidate ``` `Path.resolve` does three things at once: it makes the path absolute (against the process's current working directory, if it was relative), it removes `.` and `..` segments, and it follows symlinks so that the result names the real file the kernel would reach. `PurePath.is_relative_to` then does no I/O at all — it is a pure comparison over path components, returning `True` when the base is a prefix of the candidate's parts. ## Why the order is not negotiable A containment test on unresolved paths is meaningless. `'/srv/uploads/../../etc/passwd'` is *lexically* under `/srv/uploads` — its first components are the base's components — yet it names `/etc/passwd`. Resolving first turns the string into the destination, so the lexical test finally asks the right question. The mirror mistake is resolving the candidate but comparing against an unresolved base: if `/srv/uploads` is itself reached through a symlink, the resolved candidate lives under the *link target* and every legitimate request is rejected. Resolve the base once, at import or start-up, and treat it as a constant. ## Why str.startswith is the wrong comparison The classic broken version is `candidate_str.startswith(base_str)`. String prefixing does not respect path component boundaries: `'/srv/uploads-old/secret'` starts with `'/srv/uploads'` and passes, although it is a sibling directory the base has no authority over. People patch this by appending a separator to the base — which is nearly right, but now the base itself no longer matches, trailing-separator handling differs between the two operands, and on Windows you have two separators and case-insensitive comparison to reason about. `is_relative_to` sidesteps all of it by comparing parsed components. In the `os.path` world the equivalent is `os.path.commonpath`: build the list of the two resolved paths and require the common prefix to equal the base. Beware that `commonpath` raises `ValueError` when it is handed a mix of absolute and relative paths — which is another reason to resolve first. ## `strict`, existence, and what resolve promises `Path.resolve` takes `strict`, and the default is `False`: components that do not exist are permitted, and the path is returned with the non-existent tail attached. That is what you want for a create-file path, and it means the check works before the file is written. With `strict=True` a missing component raises `OSError`, which is useful when you want a read path proven to exist — though it also means your validator now depends on filesystem state. The `os.path` counterpart is `os.path.realpath`, whose own `strict` parameter arrived in **Python 3.10**. ## Case, encoding and the shape of the base On a case-insensitive filesystem two spellings name one file, so a comparison that is case-sensitive can reject valid requests or, worse, mislead a deny-list; `os.path.normcase` exists for exactly this normalization. Keep the base absolute and hard-coded rather than derived from configuration a caller controls, and never derive it from the current working directory, which anything in the process can change with `os.chdir`. ## Version notes worth carrying `PurePath.is_relative_to` arrived in **Python 3.9**. It once accepted extra positional arguments (mirroring `relative_to`); that form was deprecated in **3.12** and **removed in 3.14**, so write the single-argument call. If you must support older interpreters, `PurePath.relative_to` inside a `try`/`except ValueError` is the equivalent, and it has the pleasant side effect of handing you the validated relative segment. ## What the check does not buy you Containment proven at time T is a statement about the filesystem at time T. Between the check and the open, a component can be replaced with a symlink pointing elsewhere; that gap is a separate problem with a separate defence built on directory file descriptors. The check also says nothing about *authorization* — that this user may read this file inside the base — nor about what is already inside the base. It answers exactly one question, and it answers it well: does the path I am about to open live under the directory I intended?