Any feature that serves a file based on a name or path you provide, downloading an uploaded document, viewing a generated report, fetching an image, deserves a specific test called path traversal, and it's a good candidate for a hands-on how-to since it's genuinely easy to test yourself.
What this vulnerability actually is
If a download feature takes a filename and uses it directly to locate and read a file on the server's disk, without carefully restricting where that file can actually come from, it's sometimes possible to manipulate the filename to walk up and out of the intended folder, using a pattern like repeated "go up one directory" sequences, and reach an entirely different file on the server, one that was never meant to be downloadable at all, potentially including configuration files or other sensitive server-side content.
The test, step by step
- Find a feature in your app that downloads or displays a file based on a name or path passed in a request, a URL, or a form field.
- Try modifying that filename to include a pattern that means "go up one directory level" repeated several times, followed by a path to a common system file.
- Send that modified request and see what comes back. If you get an error saying the file wasn't found, or a properly restricted response, that's a good sign.
- If you get back the actual contents of a file that clearly isn't one of your app's intended documents, that's the vulnerability, confirmed directly.
Why this is worth testing even if you're confident your framework handles it
Modern frameworks and their standard file-serving utilities generally guard against the most common version of this by default now. The risk shows up specifically in custom file-handling code, a feature built to read files from disk directly rather than through the framework's built-in, already-hardened file-serving mechanism, often because the standard approach didn't quite fit whatever the specific feature needed to do. Any place your app reads a file directly using a name or path that came from a request is worth this specific test, regardless of general confidence in the framework underneath it.
The fix
Never build a file path directly from user-supplied input. Instead, validate that the requested file matches an expected, known-safe pattern, or better, use an internal reference or ID that maps to a specific, pre-approved file location, rather than trusting a raw path or filename from the request to determine what actually gets read off disk.
This is a well-understood, decades-old vulnerability class, and it's still worth checking specifically anywhere your app reads files based on user input, because the fix for the common case is usually already handled by your framework, right up until a specific feature was built to bypass that protection for convenience.