Run deliberately vulnerable apps only on localhost or a network that has no route to production or the public internet. Treat them as hostile software: bind to loopback, use throwaway containers, keep real credentials off the machine, and tear everything down after the session.
Why the risk is real
These apps contain real, intentional flaws. The OWASP WebGoat project page warns that running it makes your machine highly vulnerable to attack and advises disconnecting from the internet while using it. It also notes the default configuration binds to localhost to limit exposure. The same logic applies to any app built to be broken.
The OWASP Juice Shop page describes it as an insecure web application for security training, awareness demos and CTF challenges. It does not give explicit safety warnings, so the isolation advice below is ours, not the project's.
Setup rules
Bind to loopback. If the app listens on all interfaces, anyone on the same Wi-Fi can reach it. Keep it on 127.0.0.1 unless you need a shared lab.
Use containers, and throw them away. A fresh container per session means no leftover state and no leftover access. Remove it afterwards.
Cut the network where you can. Docker documents a none network driver that creates only a loopback device inside the container, so it has no external connectivity. Start a container with --network none when an exercise does not need outside access.
docker run --rm --network none alpine:latest ip link show
Keep real data away. No production credentials, no real customer data, no personal tokens in the shell. Use dummy accounts.
Separate lab from work. Prefer a dedicated VM or a separate machine profile over your daily browser, where saved logins might be reachable by a browser-based exploit.
For a shared lab
When many people need the same instance, put it on its own network segment with no route to internal systems. Restrict inbound access to attendees, and add an egress block so that a compromised lab host cannot call out. Hand out per-person accounts so nobody tampers with another person's state.
Put someone in charge of shutdown. Forgotten lab servers are exactly how a training tool ends up indexed on a search engine.
Rules for people
Attack only the lab. Using the techniques on systems you do not own or have authorization to test is not a training exercise. The WebGoat page itself warns that unauthorized hacking can have serious consequences.
Checklist
- Bound to localhost or an isolated segment
- Disposable container or VM
- No production credentials present
- No public DNS entry or port forward
- Named owner and a teardown time
Quick check
Is it fine to host a training app on a public cloud server?
Avoid it. A public instance can be found and abused. If you must, restrict access by IP and set an automatic shutdown.
Do I need a separate machine?
Not strictly, but a dedicated VM or profile is a cheap way to keep lab activity away from your real accounts.
Sources
Last reviewed: 19 October 2026.
