🚪 How I Bypassed a 403 Forbidden WAF Protection (and What I Learned)

🕵️‍♂️ The Beginning: Seeing a 403 on Feroxbuster

Every good story in hacking starts with a simple clue.

For me, it began with a feroxbuster scan. I was enumerating directories when I noticed multiple endpoints returning 403 Forbidden. To many people, that might look like a dead end. But for me, 403 is a signal. It means:

• There’s something valuable behind it.
• Someone doesn’t want you to see it.

And that’s exactly where I get curious.

💡 The Thought Process: Can It Be Bypassed?

When I see a 403, I don’t stop. I ask myself:

• Is this just a WAF (Web Application Firewall) filter?
• Can I trick it with encoding, path traversal, or header tampering?
• What if I look at the raw request, strip it down, and replay it differently?

This mindset is crucial. A 403 is often just a badly configured rule — and bad configs can be bypassed.

🛠 The Tools I Used

• feroxbuster → for directory discovery
• 4zero3 / bypass-403 / NoMore403 → automated 403 bypass payload testing
• curl → raw request testing (with --http1.1 and --path-as-is)
• Burp Suite → for manual inspection, replay, and automation (Turbo Intruder)

🔍 The Breakthrough: curl Wins

I found that /wp-content/xmlrpc.php returned 403 normally. But when I sent the request with obfuscation, something changed.

Normal Request (Blocked)

curl -k -o /dev/null -s -w "Status: %{http_code} | Size: %{size_download}\n" \
'https://target.com/wp-content/xmlrpc.php'

Bypass Request (Allowed)

curl -k -o /dev/null -s -w "Status: %{http_code} | Size: %{size_download}\n" \
'https://target.com/wp-content/xmlrpc.php/../../../'

Suddenly, 403 → 200. The WAF was tricked.

Other encodings also worked:

.../xmlrpc.php/%2e%2e/
.../xmlrpc.php/..;/

This confirmed that the WAF’s path normalization rules were flawed.

🎯 Why This Matters

Bypassing WAF restrictions isn’t just a fun trick. It means:

• Brute Force Amplification → Using system.multicall in XML-RPC for mass login attempts.
• DDoS → Leveraging pingback.ping as an amplifier.
• SSRF → Using XML-RPC to make internal requests.
• Sensitive File Access → Extending the same bypass to /wp-config.php or /.htaccess.

In other words, a bypass like this removes the shield the WAF was supposed to provide.

📜 Reporting It

Even though the company isn’t running a bug bounty program, I documented my findings properly and Reported.

Get samael0x4’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

Because professionalism matters — whether or not there’s a payout.

🚀 Lessons Learned

1. 403 isn’t the end — it’s often the beginning.
2. Think like a bypasser — encoding, traversal, headers, methods.
3. Keep requests minimal — sometimes a single header change is all it takes.
4. Document your findings like a pro — even if the company has no bounty, you build credibility.

This journey wasn’t about a reward — it was about the thrill of turning a 403 into a 200 and learning something powerful along the way.

🔚 Final Thoughts

If you’re a beginner in bug bounty or pentesting, remember this:

• When you see a 403 Forbidden, don’t give up.
• That “forbidden” door is often unlocked if you just try the right key.

Sometimes, the difference between “blocked” and “bypassed” is just %2e%2e. 😉