Web Pentesting From Scratch: Building a Safe Lab with DVWA, Juice Shop and Burp Suite

Some people fire up Burp Suite against the first site that pops up on Google and immediately call themselves pentesters. That is a felony in more than thirty countries, including the US under the Computer Fraud and Abuse Act. The only sane path is building your own lab, isolated and stuffed with legally vulnerable targets, before touching any real system. In this guide the Basilisk team builds a reproducible environment on a 16GB RAM box using DVWA, OWASP Juice Shop and Burp Suite Community as the starting trio. Everything runs on a VirtualBox host-only network, with zero bits leaking to the outside world, and every step is designed so you can tear it down and rebuild it in minutes.

Why a lab is the difference between research and a crime

The legal line is not about intent, it is about authorization. Scanning, fuzzing or even connecting to a system you do not own or have written permission to test is unauthorized access in most jurisdictions, regardless of whether you cause damage. A lab removes that risk entirely: the targets are software explicitly published to be broken, running on machines you control, on a network that cannot reach anyone else. It also makes you a better tester, because you can trigger a payload a hundred times, watch exactly what changes, and compare against known-good source code, which you can never do against a black-box production target.

The isolation layer that separates research from incident

Start with isolation, because that is what keeps your experiments from leaking. Create a Kali Linux 2026.1 VM with two adapters: a toggleable NAT for pulling updates and a host-only adapter on the 192.168.56.0/24 range. Target machines (one Ubuntu 22.04 running DVWA in Docker and another running Juice Shop on port 3000) stay ONLY on host-only. Drop any default route inside them with ip route del default so even a full compromise cannot phone home. Take a VirtualBox snapshot of every VM before each session; reverting after you install a sketchy Burp extension saves hours of reinstall and guarantees a known-clean baseline.

Deploying DVWA and learning the exploit cycle

Spin up DVWA with docker run --rm -it -p 80:80 vulnerables/web-dvwa and set the security level to low on first contact. The goal is not finishing every module on day one but internalizing the cycle: watch the request in Burp, tweak a parameter, watch the response, craft a payload, repeat. The DVWA SQL Injection module is the classic mind-opener: send ' OR 1=1-- - in the id parameter and watch the query return every row. Then raise the security level to medium and high to see how input validation and parameterized queries progressively close the hole, which teaches you the defensive side at the same time.

Deploying Juice Shop for realistic modern targets

Juice Shop is a brutal realism upgrade: an Angular single-page app with 100+ challenges, a hidden scoreboard, a poorly validated JWT and REST endpoints full of IDOR. Bring it up with docker run --rm -p 3000:3000 bkimminich/juice-shop and configure Burp Suite Community as a proxy at 127.0.0.1:8080. Because it is a real SPA, you will practice against JSON APIs, JWT tampering and client-side routing, which is what modern applications actually look like. The hidden scoreboard at /#/score-board gives you a structured curriculum from trivial to genuinely hard, and each solved challenge maps to a real vulnerability class.

Configuring Burp Suite the right way

Import Burp's CA certificate into a dedicated Kali Firefox profile (NEVER into your personal browser) so you can intercept TLS without training yourself to ignore certificate warnings. Then configure an aggressively tight scope: under Target > Scope add only 192.168.56.0/24 and tick the option to drop out-of-scope traffic. That single click prevents the classic intern nightmare of leaving Intruder running against a CDN. Create one Project File per target (dvwa.burp, juiceshop.burp) so findings stay clean, enable Logger++ from the BApp Store for a full audit trail, and install Param Miner to discover hidden headers and parameters.

A repeatable methodology, not random clicking

Work each target in phases: map the surface (spider plus manual browsing with proxy history), identify inputs (every parameter, header, cookie and JSON field), test one class at a time (injection, then access control, then client-side), and confirm with a minimal reliable payload before moving on. Resist the urge to run the active scanner first; understand the app manually, because the scanner will miss the logic flaws that are the most interesting bugs. Keep a running list of endpoints and their expected authorization so you can systematically test IDOR by swapping identifiers between two accounts you created.

Documentation that turns practice into skill

Document every exploit with three artifacts: the raw request, the exact payload, and expected versus observed behavior. Use a dedicated Obsidian vault for the lab, tagged along the OWASP Top 10, so patterns accumulate across targets. When you find that Juice Shop has a poorly filtered avatar upload, write the report before chasing the next challenge; that discipline is what separates a hobbyist from a professional. Keep encrypted backups of the vault, because your exploit notebook is gold and a liability the moment it leaks: it is a map of techniques and, if it ever includes a real engagement, of a client's weaknesses.

Common pitfalls that ruin a home lab

The usual failures: giving target VMs a bridged adapter so they are suddenly reachable from your home network; installing unaudited third-party Burp extensions on the same profile you use for real work; leaving the NAT adapter enabled so a target can exfiltrate; forgetting to snapshot before an experiment and losing a working setup; and, worst of all, getting comfortable and pointing the lab tooling at a live site because it felt harmless. Treat the boundary between lab and internet as sacred. Everything inside is yours to break; nothing outside is, without written scope.

Lab checklist and where to go next

Before each session verify: target VMs are host-only with no default route; Burp scope is set and out-of-scope dropping is on; per-target project files exist; snapshots are fresh; and the NAT adapter is off unless you are updating. Before closing, power off the VMs with VBoxManage controlvm <name> poweroff, revoke the temporary NAT, and revert to a clean snapshot if you installed anything experimental. When DVWA and Juice Shop feel easy, graduate to HackTheBox, TryHackMe or bug-bounty programs with written scope, where the same discipline keeps you legal.

FAQ: Is Burp Suite Community enough, or do I need Pro?

Community is enough to learn everything in this guide. The main limits are a throttled Intruder and no built-in active scanner. For a learning lab that is actually a feature, because it forces you to understand attacks manually instead of clicking scan. Buy Pro only when you are doing paid engagements where the automated scanner and faster Intruder save billable hours; until then, Community plus free BApp extensions like Logger++ and Param Miner covers the curriculum.

FAQ: Can I run all of this on one laptop?

Yes. Kali plus two lightweight Ubuntu target VMs fits comfortably in 16GB of RAM if you give Kali 4GB and each target 2GB. If memory is tight, run DVWA and Juice Shop as Docker containers on a single Ubuntu target instead of two separate VMs. The non-negotiable part is the host-only network and the snapshots; the exact VM count is flexible and you can scale down without weakening the isolation.

Scripting the lab so it rebuilds itself

A lab you cannot recreate on demand quietly rots: extensions drift, target versions fall behind, and one bad snapshot revert loses your setup. Treat the whole thing as code. Describe the VMs in a Vagrantfile and the provisioning (Docker install, DVWA and Juice Shop containers, host-only network, Sysmon or logging tweaks) in an Ansible playbook or a plain shell script, so a single vagrant up reconstructs the environment from scratch. Keep the target image versions pinned but bump them deliberately each quarter, because Juice Shop and DVWA both ship new challenges and patched behaviors that change what your practice covers. Store the whole definition in a private Git repo, never with any real credentials or engagement data committed, and tag a known-good state before large changes. The payoff is twofold: you can throw the environment away without fear after testing something destructive, and you can hand the exact same lab to a teammate so your findings are reproducible rather than folklore. Reproducibility is the single habit that most cleanly separates a serious practitioner from someone who got a shell once and could never do it again.

Practical takeaway: treat your lab like a small nuclear reactor with an operations log, segregated networks and mandatory snapshots. When you are confident with DVWA and Juice Shop, move to HackTheBox, TryHackMe or bug-bounty programs with written scope. Practice without scope is not a pentest, it is a crime that carries years in prison in many countries. Lab discipline is what keeps you on the right side of that line, and it is the exact same discipline that makes professional engagements clean and defensible.