Path traversal from an unvalidated request parameter
Part of Security, which counts for 30% of the overall score. When this check fires it deducts 8 points from that category, once per scan, no matter how many places it turns up.
What it detects
A @PathVariable or @RequestParam value is passed directly into new File(...), Paths.get(...), or a file stream constructor with no visible normalization or allow-list check, so a value like ../../etc/passwd can escape the intended directory. Heuristic: it cannot see validation performed in a helper method it does not scan.
Why it matters
Passing a @PathVariable or @RequestParam value straight into new File(...), Paths.get(...), or a file-stream constructor lets a value like ../../etc/passwd (or an absolute path on some platforms) escape the directory the endpoint intended to serve from. This is one of the most common ways an otherwise ordinary "download a file by name" endpoint turns into arbitrary file read.
How to fix it
Resolve the requested name against a fixed base directory and reject anything that normalizes outside it (compare the resolved real path's parent against the base directory), or better, use an opaque identifier (a database key, not a filename) to look up the file server-side instead of trusting a client-supplied path fragment at all.
The paid report includes a ready-to-paste prompt for your AI coding agent for every check it finds, pointed at the exact findings from your scan. See pricing
Does your repo trip this check?
Paste a GitHub URL or drop a project folder. Scans run in your browser and take seconds.
Scan your repo