July 4, 2026
The Biggest Path Traversal Mistake I Didn’t Know I Was Making — Here’s The Path Traversal Checklist…
A few weeks ago, I was testing a web application when I noticed something that looked interesting — a “.jpeg” file being loaded by the…
By Swati Choudhary
3 min read
A few weeks ago, I was testing a web application when I noticed something that looked interesting — a ".jpeg" file being loaded by the application.
My brain immediately went into "time to find a Path Traversal vulnerability" mode.
I started throwing payloads at it. Basic traversal, encoded payloads, different bypasses… if it was on my checklist, I probably tried it.
Nothing.
At first, I blamed the application.
"Looks like they've secured this pretty well."
But the more I looked at it, the more something felt off. Why wasn't anything behaving the way I expected?
The answer had nothing to do with my payloads.
It had everything to do with what I was testing.
The file path was hard-coded. My input never influenced it in the first place.
In other words, I was trying to exploit a vulnerability where there wasn't even an attack surface.
That small realization completely changed how I approach Path Traversal testing. Before thinking about payloads or bypasses, I now ask a much simpler question:
"Can user input actually control the file path?"
If the answer is no, it's time to move on.
If the answer is yes, that's when the real testing begins.
This article is the checklist I wish I had on day one — a methodology to help you identify what is actually worth testing before you spend the next 30 minutes throwing "../../../etc/passwd" at something that was never vulnerable in the first place.
Step 1: Before You Touch a Single Payload, Ask This One Question
This is the mistake that cost me the most time.
When you see a feature that loads a file — an image, a PDF, a report, a template — it's tempting to jump straight to:
../../../etc/passwd
Resist the urge.
Instead, ask yourself a much simpler question:
"Can I actually control the file that's being accessed?"
If the answer is no, congratulations — you've just saved yourself from testing something that was never vulnerable in the first place.
Look for places where the application reads, downloads, displays, or includes files. Then figure out where that file path comes from.
Ask yourself:
Can I influence the filename through a parameter like "file=", "page=", or "doc="?
Can I modify it through a POST request, cookie, or even a header?
Is the application building the path using something like "base_directory + user_input"?
Here's the difference:
Hard-coded
/images/profile.jpeg
The application always loads the same file. Your input doesn't matter, so Path Traversal isn't a realistic attack here.
User-controlled
/download?file=report.pdf
Now your input decides which file gets opened.
That's where your testing should begin.
The biggest lesson I learned wasn't a new payload — it was realizing that an attack only works if you can influence the thing being attacked.
Step 2: Does the application let you step outside?
You've confirmed that the file path is influenced by user input.
Now it's time to answer the next question: Can you escape the directory the developer intended you to stay in?
Start with simple traversal sequences like ../ (or ..\ on Windows). If the payload works, great — you've confirmed directory traversal.
If it doesn't, don't stop there.
Pay attention to how the application responds.
Does the response change?
Do you get a different error message?
Is your input being normalized or sanitized?
Is the application rejecting your input altogether?
Your job at this stage isn't to prove impact.
It's to answer one question:
"Can I escape the directory the developer expected me to stay in?"
Step 3: Don't trust the first "NO" — time to test the filters.
You tried "../".
The application rejected it.
Look like a dead end? not quite.
All You've learned so far is that the application doesn't like ../.
What you haven't learned yet is whether it actually fixed the vulnerability.
There's a big difference.
Some applications block the exact string "../" and call it a day. Others decode, normalize, or process your input in ways that can unintentionally bring it back.
This is where a few well-chosen variations are worth trying.
URL Encoding: "..%2f" ("%2e" = ".", "%2f" = "/")
Double Encoding: "%252e%252e%252f" (useful if input is decoded more than once)
Mixed Separators: "../" or ".." (depending on the target platform)
Normalization Tricks: Variations like "….//" can sometimes bypass naive string replacement filters.
Notice the pattern?
You're not randomly changing payloads.
Each variation is testing a different assumption about how the application processes your input.
The goal isn't to find a payload that works. It's to understand why one works when another doesn't. Once you understand that, you're no longer guessing — you're testing.
Step 4: Now Prove Why It Matters
Congratulations — you've confirmed Path Traversal.
But hold on.
Reading "/etc/passwd" is a proof of concept, not the end goal.
Now ask yourself:
"What can an attacker actually access because of this?"
Look for files that have real security value, such as configuration files, ".env" files, source code, logs, or credentials. Focus on demonstrating impact, not just file access.
A single exposed secret is often a much stronger finding than dozens of harmless files.
Remember: Don't collect files. Collect impact.
Final Thoughts
If there's one thing I hope you take away from this article, it's this:
Don't start with payloads. Start with questions.
One of the biggest mistakes I made was assuming that every file-handling feature deserved Path Traversal testing. It doesn't.
The first payload should never be "../../../etc/passwd".
The first question should always be:
"Can I actually influence the file path?"
That one question has saved me far more time than any payload list ever could.
This checklist isn't meant to replace your creativity or experience. It's simply a reminder that good testing isn't about trying more payloads — it's about asking better questions.
If you're just starting out in web security, I hope this methodology helps you avoid the same mistake I made and spend more time testing the things that actually matter.