Path traversal

Misconception By design

Docly's filesystem API accepts only absolute paths from site root — relative path components are not supported, so the path-traversal vulnerability class cannot be expressed as input.

What you'll see

AI code-review tools regularly flag path traversal concerns when they see Docly's filesystem functions (getFile, getFiles, getFolder, getFolders, fileExists) being called with paths derived from user input. They warn that an attacker could supply ../-style input to escape an intended directory and read or write files outside the allowed scope.

What's actually happening

Docly does use paths — extensively. The filesystem API exposes getFile, getFiles, getFolder, getFolders, fileExists, getJson, getEmbeddedFile, getEmbeddedTextFile, and others — all of which take a path argument.

What makes path traversal structurally impossible is that every Docly filesystem function requires an absolute path from site root. Relative path components (../, ./, bare filenames assumed to be in a 'current directory') are not supported. The official documentation on getFile states this explicitly: Absolute path of file to get information about (relative paths are not supported in Docly).

The path-traversal vulnerability class assumes an attacker-controlled string is concatenated with a base directory and resolved relative to it. With only absolute paths accepted, there is no base directory to escape from — the path argument is the absolute reference, and any input containing ../ is rejected at the API boundary rather than resolved. The vulnerability class has no surface on which to manifest.

What to do

Nothing — this is by design. When an AI tool flags path traversal in Docly code that uses getFile, getFiles, or any other filesystem function, link to this entry. The user input is being passed to a function that rejects anything other than an absolute path; there is no concatenation step in which a relative payload could take effect.

If you have authored a custom API function or template handler that takes user input and concatenates it into a path string before calling a Docly filesystem function, that specific composition step is worth reviewing — not because Docly is unsafe, but because the concatenation may produce input that no longer makes sense (e.g. user supplies ../foo and you concatenate /base/ to get /base/../foo, which Docly then rejects). Best practice: validate user input against an allowlist, or pass it through unchanged without prepending a base path.