I Ignored the Lab Instructions and Solved It My Own Way -Here’s What I Learned

You know that feeling when a tutorial tells you exactly which tool to use, and your brain immediately says "nah, let me try something else"? That's what happened to me with this PortSwigger lab.

The lab explicitly said: use Burp Suite's Param Miner. My response: "I'm tired of Burp. Let me try ZAP instead." Spoiler: it worked. And I learned something important in the process.

The Problem: URL-Based Access Control

The lab setup was straightforward: there's a protected endpoint that should only be accessible to certain users. The access control is implemented at the URL level, Meaning the server checks the request path and decides whether to grant access.

My job: find a way to bypass it.

Normally, the recommended path is Burp Suite's Param Miner, A powerful tool that guesses parameter and header names from a wordlist. It works great if you have Burp Pro (or don't mind the Community Edition's limitations).

But here's the thing: Param Miner doesn't do anything magical. It iterates through a wordlist, sends requests, and analyzes responses. That's literally what a fuzzer does. So why not just use ZAP's fuzzer instead?

The Setup: Custom Headers + ZAP Fuzzer

I grabbed my custom header wordlist, it includes:

• X-Forwarded-* variants (the classics for proxy bypass)
• Path manipulation headers (X-Original-URL, X-Rewrite-URL, etc.)
• Auth spoofing attempts (X-Authenticated-User, X-Role, X-Admin)
• Internal/debug flags (X-Internal, X-Bypass, X-Debug)
• Proxy tricks (X-Backend-Host, X-Gateway, X-Proxy)

Then I set up ZAP's fuzzer with:

1. Input: My custom header list
2. Processor: Postfix with: /abc appended to the URL path
3. Target: The protected endpoint
4. Profit: Watch the responses change

The Results: It Actually Worked

The fuzzer ran through headers and found that bypassed the access control:

• (original request): 404 Not Found

The signal was clear: when certain headers were added + the URL was modified with the postfix, the server's access control check failed completely.

I'd successfully bypassed URL-based access control without using a single Burp Suite feature.

The POC 👈

Why This Actually Matters

1. Tools are interchangeable for many tasks

Burp's Param Miner is excellent, ZAP's fuzzer does the same fundamental thing iterate, send, analyze. If you understand what the tool actually does, you can often substitute it with something else.

2. Your wordlist is more valuable than the tool

The real asset here isn't ZAP or Burp, it's the custom header list.

When you run a fuzzer, you're only as good as your wordlist. A mediocre tool with a great wordlist beats a great tool with a mediocre wordlist every time.

3. Don't blindly follow recommendations

The lab said "use Param Miner." My brain said "but can ZAP do this?" Instead of assuming the answer was no, I just… tried it. And it worked.

This mindset is crucial in security work. You encounter recommendations constantly "use this tool," "follow this methodology," "do this technique." But testing assumptions is faster than memorizing gospel. If you understand the problem, you can often find multiple valid solutions.

How to Apply This Yourself

If you're learning access control testing:

1. Don't assume one tool is your only option
2. Build a custom wordlist as you go (save headers that work, parameters that matter, paths that bypass)
3. Test with whatever fuzzer you have access to. Burp, ZAP, or even a bash loop
4. Look for response signals: status code changes, body size differences, content variations

If you're in bug bounty:

1. Start collecting headers, parameters, and payloads that work on your targets
2. Test with your preferred tool (Burp, ZAP, custom scripts. doesn't matter)
3. Iterate on your wordlists constantly; they're your real competitive advantage
4. Share what you learn; the security community benefits from shared knowledge

The Real Lesson

This lab taught me something beyond "ZAP can fuzz headers." It reinforced that methodology matters more than tooling. You can solve the same problem in multiple ways if you understand the underlying vulnerability and have good reconnaissance data (your wordlist).

Burp Pro is great. ZAP is free and solid. Custom bash scripts work too. Pick your tool, grab your wordlist, and test systematically. That's what actually finds vulnerabilities.

Next time a lab tells you to use a specific tool, don't blindly follow it. but don't reject it either. Understand why it's recommended, then decide if your approach can do the same thing. You might surprise yourself.

P.S. I've open-sourced my custom header list on GitHub. If you're building your own wordlist, grab it and start testing. And if you find headers that work for you, contribute them back. That's how we all get better.