Build a Safe OWASP Juice Shop Lab in 7 Proven Steps

OWASP Juice Shop is an intentionally insecure web application designed for legal security training, and the safest way to run it is inside a controlled lab with no trusted devices or public services sharing its network. A proper setup isolates the target, limits which interface can reach port 3000, preserves clean snapshots, and gives you a repeatable way to stop or reset the application.

In this guide, I show how I build a safe OWASP Juice Shop lab in 7 proven steps. The focus is not merely getting the shop to load. That part is easy. The useful work is making sure the deliberately vulnerable target stays where it belongs while Parrot OS, Burp Suite, and your browser can still reach it.

If you enjoy practical experiments that explain both the command and the reason behind it, you can join my HackersGhost newsletter. I share new lab notes, security lessons, and the occasional reminder that a green terminal does not automatically mean the network design is green too.

This OWASP Juice Shop tutorial assumes you are using your own hardware, virtual machines, and isolated network. Do not point testing tools at the public demo or any website you do not own unless you have explicit authorization. The target may be fictional, but scope is still real.

Proven step	Safe lab decision	What it prevents
1. Define the boundary	Choose the exact VMs and subnet	Accidental scope drift
2. Isolate networking	Use a LAN segment, host-only network, or disconnected router	Exposure to trusted devices
3. Prepare the target	Build and snapshot an Ubuntu VM	Messy, irreversible changes
4. Run the application	Publish Docker only on the required interface	Unnecessary port exposure
5. Connect the attacker	Allow Parrot OS onto the lab network only	Testing the wrong network
6. Separate tools	Use a dedicated browser profile and proxy	Mixing personal and lab data
7. Verify and reset	Test isolation, record results, and restore clean state	Configuration drift

Key Takeaways

• Network isolation is the primary safety control. A VPN can protect internet traffic, but it does not contain an intentionally vulnerable VM.
• The official OWASP Juice Shop Docker image makes deployment simple, but the host interface used for port publishing still matters.
• A two-VM design gives you a realistic attacker-and-target workflow without placing the target on your normal home network.
• Snapshots are part of the methodology. They let you repeat a test without turning yesterday’s experiment into today’s unexplained behavior.
• A separate browser profile keeps proxy certificates, fake credentials, and test traffic away from your personal browsing.
• You should verify isolation from both directions instead of trusting a network-mode label.
• The goal of an OWASP Juice Shop lab is repeatable learning, not collecting challenge badges at maximum speed.

What Is OWASP Juice Shop?

If you are wondering what is OWASP Juice Shop, it is an open-source training application built to contain security weaknesses on purpose. The Open Worldwide Application Security Project supports it as a platform for security training, awareness demonstrations, capture-the-flag exercises, and testing security tools.

The application resembles a modern online store rather than an ancient page with three text boxes and a background last seen near a dial-up modem. It has users, products, baskets, an API, a challenge scoreboard, and a client-and-server OWASP Juice Shop architecture. Its intended flaws cover the OWASP Top Ten and other realistic application-security problems.

That realism makes the OWASP Juice Shop project valuable. You can observe requests, authentication decisions, access-control mistakes, validation failures, and business logic in an environment created for learning. It is a training target, not a model application to copy into production.

HackersGhost Note: I treat the scoreboard as feedback, not as the entire lesson. If I solve something but cannot explain the request, response, and broken security assumption, I have completed a challenge without fully completing the learning.

My Safe Web Hacking Lab Architecture

My ethical hacking virtual lab runs on a second-hand HP EliteBook. I added 16 GB of RAM, bringing it to 32 GB and giving VMware room for an attacker and target VM without making the latest Windows version negotiate for every remaining megabyte.

I chose VMware because it fits my workflow better. I keep Kali Linux and Parrot OS available, but Parrot OS is the system I use most often. Ubuntu runs OWASP Juice Shop in Docker, while Parrot holds my browser, Burp Suite, and testing tools.

I separate network roles physically. My Cudy WR3000 handles ordinary internet traffic through ProtonVPN WireGuard with Secure Core, sometimes using privacy-oriented routes involving Switzerland or Iceland. My TP-Link Archer C6 is reserved for controlled experiments, connects to the lab side of my laptop, and is not connected to the modem.

My privacy network and web application security lab are therefore separate. ProtonVPN supports permitted external traffic; the disconnected router, VMware settings, and interface binding contain the target. Different controls, fewer networking ghosts wearing each other’s name badges.

HackersGhost Note: My most useful lab improvement was not installing another tool. It was deciding which network each machine was allowed to see before starting the target. That decision made every later test easier to understand.

Step 1: Define the OWASP Juice Shop Lab Boundary

Before installing anything, define your safe web hacking lab. Mine contains one Parrot OS attacker, one Ubuntu target, one private subnet, and no internet port forwarding. Trusted devices and ordinary browsing stay outside.

My rules are simple: only the target hosts the application, only the attacker tests it, normal Wi-Fi cannot reach it, and internet access can be removed after installation. Each rule is verifiable.

If Ubuntu needs internet for updates or the container image, attach NAT only for maintenance and disconnect it before testing. A forgotten second adapter lets the VM quietly use a network missing from your diagram.

Step 2: Choose the Right VMware Network

Use a LAN Segment for Strong VM-to-VM Isolation

A VMware LAN segment is my cleanest software-only option. Parrot and Ubuntu can communicate, but the segment has no automatic route to the host, home LAN, or internet. Static addresses may be necessary because DHCP is not built in.

Use Host-Only When Convenience Matters

Host-only networking is convenient when the host needs management access and DHCP. The host participates, so I do not treat it as identical to a VM-only segment, and I verify that forwarding is disabled.

Use a Disconnected Router for a Physical Lab

My TP-Link Archer C6 provides a physical network for packet capture and router experiments. Its WAN stays disconnected, so the attacker and target share a private subnet without a route into my trusted network. This makes the OWASP Juice Shop lab feel like a small real network.

I avoid ordinary bridged mode unless it points only to the isolated adapter. Bridging the target to normal Wi-Fi may place it beside every trusted device. The application should leak lessons, not invitations.

Step 3: Build and Snapshot the Ubuntu Target

I start the target with two virtual CPUs, around 4 GB of RAM, and enough disk for Ubuntu, Docker, logs, and snapshots. Giving an intentionally vulnerable shop every available resource mostly provides it with a larger office.

I install Ubuntu, apply updates during maintenance, add VMware tools, and confirm the adapter. I create a clearly named snapshot before installation and another after Docker and the application work correctly.

“Snapshot 4” becomes archaeological evidence after a few weeks. I also keep personal accounts, cloud folders, password extensions, clipboard sharing, and unnecessary host folders off the target. Its lab data should be disposable.

HackersGhost Note: I take a snapshot before the interesting work, not after something behaves strangely. A clean checkpoint is a lab instrument. A snapshot of unexplained chaos is merely chaos with a convenient restore button.

Metasploitable 2 Tutorial: How to Practice Ethical Hacking Safely

Metasploitable 2 Tutorial: How to Practice Ethical Hacking Safely

Step 4: Install OWASP Juice Shop With Docker

For most beginners, OWASP Juice Shop Docker is the simplest deployment method. The container is easy to start, remove, and recreate. I still place it inside Ubuntu so the VM adds a clear boundary around it.

I install Docker using Ubuntu’s supported method and verify it before pulling the image. The Docker homepage is my starting point when installation details change.

sudo apt update
sudo apt install docker.io -y
sudo systemctl enable --now docker
sudo docker version
sudo docker pull bkimminich/juice-shop

If you want to learn how to set up OWASP Juice Shop on one machine only, bind the published port to localhost. This follows the safe default used by the official project instructions:

sudo docker run --rm \
  -p 127.0.0.1:3000:3000 \
  bkimminich/juice-shop

Browse to http://localhost:3000 from Ubuntu. Binding to 127.0.0.1 blocks other VMs, which suits a single-machine exercise.

For two VMs, I bind only to Ubuntu’s isolated interface. With 192.168.0.203, the command becomes:

sudo docker run -d \
  --name juice-shop \
  -p 192.168.0.203:3000:3000 \
  bkimminich/juice-shop

Use your target’s actual lab-only address. I avoid -p 3000:3000 because Docker may publish on every host interface. Convenience should not quietly redesign the OWASP Juice Shop lab.

Finally, I confirm the container and listening socket:

sudo docker ps
sudo docker port juice-shop
ss -lnt | grep 3000
curl http://192.168.0.203:3000

Step 5: Connect Parrot OS to OWASP Juice Shop

Parrot uses the same isolated network as Ubuntu. For example, Parrot may use 192.168.0.159 and Ubuntu 192.168.0.203. Both are private lab addresses.

ip -br address
ip route
ping -c 3 192.168.0.203
curl -I http://192.168.0.203:3000

The browser should load OWASP Juice Shop at http://192.168.0.203:3000. The target should not reach my normal router, and trusted Wi-Fi devices should not reach port 3000.

A failed ping alone proves little because other traffic may still pass. I inspect routes, check every adapter, test port 3000 from Parrot, and repeat from a trusted device. A safe web hacking lab earns confidence through several checks.

Step 6: Prepare a Dedicated Browser and Proxy

To learn how to use OWASP Juice Shop, I create a dedicated browser profile with no personal history, saved cards, synced passwords, or everyday sessions. All accounts and passwords are invented for OWASP Juice Shop.

I proxy that profile through Burp Suite on Parrot. Any testing certificate stays inside the lab profile instead of my normal system trust store. OWASP Juice Shop commonly uses HTTP locally, but the separation remains valuable for later targets.

I first browse with interception off, inspect ordinary requests, and repeat one action while watching what changes. This creates an OWASP Juice Shop penetration testing workspace instead of a browser attached to a scoreboard.

HackersGhost Note: A separate browser profile costs nothing and removes a surprising amount of confusion. When every cookie and account belongs to the exercise, I can reset the session without wondering whether I just logged myself out of something important.

Step 7: Test, Stop, Reset, and Document the Lab

My final proven step is operational discipline. I record the addresses, network mode, container, port, snapshot, and isolation results. This prevents me from troubleshooting an old address after DHCP has moved the furniture.

When I finish, I stop OWASP Juice Shop rather than leaving it running:

sudo docker logs --tail 50 juice-shop
sudo docker stop juice-shop
sudo docker ps -a

To continue, I use sudo docker start juice-shop. For a fresh application instance, I remove the container and repeat the original command. A VMware snapshot resets the wider VM.

sudo docker stop juice-shop
sudo docker rm juice-shop

I confirm temporary NAT is gone before testing. The OWASP Juice Shop guide teaches application security; my notes reveal whether a result came from OWASP Juice Shop, Burp, Docker, VMware, or networking.

How I Use OWASP Juice Shop for Practical Learning

I start as a normal user: create a fake account, browse products, use the basket, submit feedback, and watch the requests in Burp. That establishes how OWASP Juice Shop behaves before I investigate intended weaknesses.

I choose beginner challenges from the scoreboard and avoid copying an entire OWASP Juice Shop walkthrough. A hint can advance the lesson; a pasted solution may advance only the badge.

For each exercise, I record the feature, expected boundary, changed request, response, and defensive lesson. This connects OWASP Juice Shop vulnerabilities to input handling, authentication, access control, sessions, and business logic.

I repeat selected challenges after a snapshot restore. If I can reproduce and explain the behavior, the OWASP Juice Shop lab is working. If I only remember where somebody else’s payload goes, the lesson is still stuck in the carton.

What the OWASP Juice Shop Architecture Teaches

The OWASP Juice Shop architecture combines a client tier, server logic, APIs, and data storage. Browser actions create requests you can inspect, modify, repeat, and compare across multiple security categories.

A visual interface is not a security boundary. Hidden buttons and client-side checks affect what you see, but the server must enforce authorization and validation. OWASP Juice Shop lets you examine that relationship safely.

In a structured web application security lab, the browser, proxy, logs, captures, and server responses describe one event from different angles. Learning how those angles connect is the real skill.

OWASP Juice Shop Lab Mistakes I Avoid

Bridging the Target to My Normal Home Network

Ordinary bridged mode is convenient, but convenience is not my priority for a deliberately vulnerable target. I use a dedicated VMware network or bridge only to a physically isolated adapter.

Publishing Docker on Every Interface

The short Docker syntax can expose port 3000 more broadly than intended. I bind OWASP Juice Shop to 127.0.0.1 for local practice or to the specific lab-only IP for two-VM testing.

Forgetting a Temporary NAT Adapter

I use internet access for updates, not as a permanent feature of the target. After pulling the image, I remove the route and verify the adapter list again.

Assuming a VPN Is Lab Isolation

A VPN encrypts and routes selected traffic. It does not stop a vulnerable VM from talking to nearby devices on the same local network. My OWASP Juice Shop lab is contained by network design first.

Using Personal Accounts in the Target

I use invented identities and unique lab passwords. There is no educational value in placing real contact details inside a target designed to mishandle data.

Skipping the Reset Plan

Containers make recreation easy, while snapshots restore the VM around them. I prepare both before testing so that resetting OWASP Juice Shop takes minutes instead of becoming a small systems-administration memoir.

Wireshark Display Filters: 25 Essential Filters for Beginners

Wireshark Display Filters: 25 Essential Filters for Beginners

Where Proton Unlimited Fits Around My Lab

I use ProtonVPN through my Cudy WR3000 for permitted external traffic. Secure Core adds a privacy-focused routing option. The target stays on the disconnected lab side because VPN privacy and isolation solve different problems.

For me, Proton Unlimited is coherent because one subscription combines VPN access, encrypted mail, cloud storage, and a password manager. It supports the daily side of my setup while the isolated network supports OWASP Juice Shop testing.

Proton Unlimited bundles ProtonVPN, Proton Mail, Proton Drive, and Proton Pass under one subscription. If you already use Proton services around your lab and everyday privacy setup, the complete bundle is usually the more practical choice.

The Cudy WR3000 in My Network Design

My Cudy WR3000 is not the vulnerable router. It handles WireGuard and ProtonVPN on the trusted side, while the disconnected TP-Link carries experimental traffic. Clear roles keep OWASP Juice Shop away from the wrong network.

A second router is optional, but the Cudy is useful for separating normal privacy traffic from experiments. Document its WAN, LAN, and VPN roles; another box does not automatically create isolation.

My Repeatable OWASP Juice Shop Workflow

Once the OWASP Juice Shop lab is built, I use the same sequence for each session:

1. Confirm the VMware adapters. Ubuntu and Parrot should have only the connections required for this exercise.
2. Check the private addresses and routes. I verify them instead of trusting notes from the previous session.
3. Start OWASP Juice Shop manually. I confirm the container name, bound address, and port.
4. Test permitted and forbidden paths. Parrot should connect; trusted devices and public networks should not.
5. Open the dedicated browser profile. The proxy, cookies, certificates, and fake credentials remain inside the lab context.
6. Choose one learning objective. I focus on a request flow or security control instead of opening five tools because they look industrious.
7. Save notes and stop the target. I record what changed, close the container, and restore a snapshot when the next session needs a clean state.

This routine keeps the target predictable and helps separate application findings from proxy problems, stale cookies, wrong routes, or a stopped container. Not every mystery needs a vulnerability label; sometimes the service is taking the day off.

Is OWASP Juice Shop Good for Beginners?

Yes. OWASP Juice Shop gives beginners a modern, hands-on target instead of only abstract definitions. Its interface and scoreboard provide direction, while one lab supports browser inspection, proxy practice, API observation, and defensive analysis.

Separate setup from exploitation: first make the OWASP Juice Shop lab safe and repeatable, then learn one request flow at a time. You do not need every badge for the environment to be useful.

Final Thoughts on These 7 Proven Steps

The best OWASP Juice Shop tutorial begins before the first payload. Define the boundary, isolate networking, snapshot the target, publish Docker carefully, connect only the attacker, separate browser data, and plan the reset. These seven proven steps create a controlled environment.

My second-hand EliteBook, 32 GB of RAM, VMware, Parrot, Ubuntu, Cudy router, and disconnected TP-Link give every component a clear role. You can build a smaller OWASP Juice Shop lab with the same principles.

Once OWASP Juice Shop is reachable only where you intended, take the clean snapshot and begin with normal browsing. Learn what the application does before asking how it fails. That habit travels well beyond this lab.

Frequently Asked Questions