Setting Up a Legal Bug Bounty Practice Lab
Before you test a real program’s scope, you need somewhere to make mistakes for free: break authentication, break input validation, break access control, and see exactly what a working exploit looks like, without any question about whether you’re allowed to be there. This is that setup — three platforms you can use today, entirely legally, and the VM discipline to keep your practice environment separate from everything else you run.
PortSwigger Web Security Academy (start here)
This is free and is the most structured option available. Its labs are hosted on PortSwigger’s own infrastructure, not something you install — testing them is legal because PortSwigger explicitly built and authorised them for exactly this purpose, not because you own the servers. Many labs run entirely through the browser; others expect you to route your traffic through Burp Suite (covered below) so you can intercept and edit requests, which is normal and part of the exercise. Each vulnerability class — SQL injection, cross-site scripting, SSRF, access control, authentication flaws, and dozens more — has a written explanation of the underlying mechanism, then a series of deliberately vulnerable “labs,” each a real disposable web application you attack until you get a specific proof (usually reading a flag, deleting another user’s account, or similar). The lab tells you immediately whether your exploit actually worked, not just whether you found the theoretical bug.
Start with the SQL injection and cross-site scripting sections even if you’ve read about them before — the labs escalate from textbook cases into realistic evasions (filtered characters, WAF-style blocks, second-order injection) that teach you to adapt an approach, not just paste a known payload.
OWASP Juice Shop (a full application to attack)
Where the Academy teaches one vulnerability class at a time in isolation, OWASP Juice Shop is a complete, intentionally vulnerable e-commerce application containing dozens of challenges across every OWASP Top 10 category, chained together the way a real target actually is. Run it locally with Docker:
docker run --rm -p 127.0.0.1:3000:3000 bkimminich/juice-shop--rm removes the container when you stop it, so you always start clean. -p 127.0.0.1:3000:3000 binds the app to your loopback interface only, so it’s reachable at http://localhost:3000 but not from your network. Plain -p 3000:3000 would publish it on every interface on the host, which you don’t want for a deliberately vulnerable app. Once the image is pulled, the running application itself never needs internet access, though the first docker run does fetch the image from Docker Hub.
DVWA (Damn Vulnerable Web Application)
DVWA is older and rougher around the edges than the two above, but it has one feature worth knowing: a difficulty slider (low, medium, high, impossible) for each vulnerability. Attack the same bug class at “low” until it’s trivial, then move to “medium” and watch your exact same approach get blocked by a half-effective filter — that gap is where you learn to actually understand a defence instead of just bypassing an absent one. Run it the same way, with Docker, entirely isolated on your own machine.
The VM discipline: isolate the lab from everything else
Run your attacking tools (Kali or Parrot OS, or just Burp Suite Community Edition on your normal machine) in a dedicated VM, and keep vulnerable targets like DVWA and Juice Shop in containers or VMs on the same isolated network, never bridged onto your home or work network. The lab-setup discipline is identical to what’s covered in setting up a Linux lab: snapshot before you break something, and don’t be precious about resetting a VM to a clean state — that’s what it’s for.
A concrete setup that works well: VirtualBox with a Host-Only or Internal network (not Bridged, so your lab traffic never reaches your real LAN), one VM for tooling, containers for the vulnerable targets on that same internal network. If you haven’t set up VirtualBox networking before, the practical differences between NAT, Bridged and Host-Only modes matter here specifically — get this wrong and you can accidentally expose a deliberately-vulnerable app to your real network.
Burp Suite: the one tool worth learning early
Burp Suite Community Edition is free and is what almost every one of the labs above assumes you’re using. Its core value for a beginner is the Proxy: it sits between your browser and the target, lets you see and edit every request before it’s sent, and replay it endlessly. Most early “aha” moments in web security come from watching a request in Burp’s Proxy tab and realising the application trusted something it should have validated — a parameter, a cookie, a hidden field — and editing that one value by hand.
A realistic first week
- Set up the isolated VM network described above, once, properly.
- Work through PortSwigger’s SQL injection and XSS sections in full, including the harder labs, not just the first two.
- Spin up Juice Shop and try to solve five challenges without looking up a walkthrough. Then look up the ones you couldn’t solve and read why, not just the answer.
- Read your own notes back after a week. If you can explain why each exploit worked, in your own words, to someone else — you’re ready to start reading real program scopes.
Common questions
Do I need Kali Linux specifically?
No. Kali is a Debian-based distribution that ships common security tools pre-installed, which is convenient, but Burp Suite Community Edition and Docker run fine on any Linux, macOS or Windows machine. Use Kali if you want the convenience; don’t treat it as a requirement.
Is it legal to run these locally?
Yes — PortSwigger’s Academy, Juice Shop and DVWA are all explicitly built and distributed for this purpose, run entirely on infrastructure you control, and none of them involve testing any system you don’t own.
How do I know when I’m ready to move to a real program?
When you can independently identify which vulnerability class a lab is testing before reading the hint, and can explain the fix a developer would need to make — not just reproduce a payload you memorised.
Keep reading
- Bug Bounty Hunting for Sysadmins: Where to Actually Start — Where to begin with bug bounty as a sysadmin.
- Reading a CVE Like a Sysadmin: What Actually Matters in a Security Advisory — Understand vulnerability reports.
- Build a Cheap Linux Lab That Looks Like Work (Job Seekers) — Build a home lab to practise safely.
