Run a deliberately vulnerable training app on your own machine, bound to localhost, with nothing sensitive on it, and test only that target. Use an intentionally insecure project built for learning, keep it off public networks, and never point your tools at systems you do not own or have written permission to test.
Pick a training target
Two well known options come from OWASP.
- OWASP Juice Shop describes itself as an insecure web application for security trainings, awareness demos and CTFs. It is written in Node.js, Express and Angular, is MIT licensed, and tracks your progress on a score board. It is also used as a target for security tools and scanners, particularly for JavaScript-heavy frontends and REST APIs.
- WebGoat is a deliberately insecure Java application meant as an interactive teaching environment for web application security.
The project pages link to the source repositories and documentation for setup. Follow those instructions for your platform.
Contain it
WebGoat's project page is direct about the risk: your machine is highly vulnerable while it runs, so disconnect from the internet during use. It also notes that WebGoat binds to localhost by default and that you should keep it that way.
Good habits for any training app:
- Run it in a container or a virtual machine you can delete.
- Bind it to localhost, not to all network interfaces.
- Keep a separate browser profile for testing.
- Do not reuse real passwords or log into real accounts in that profile.
- Snapshot or rebuild the environment when you are done.
Add a testing proxy and a guide
An intercepting proxy lets you see and change requests. Pair it with a structured guide so you test methodically. The OWASP Web Security Testing Guide is a flagship OWASP documentation project for web application developers and security professionals. Its latest listed release is 4.2, and version 5.0 is in development.
A first set of exercises
| Exercise | What you learn |
|---|---|
| Log in, then change an ID in a request | Broken access control |
| Submit unexpected characters in a form | Input handling |
| Read response headers | Misconfiguration basics |
| Inspect stored cookies | Session handling |
| Run a scanner against the app | What automated tools find and miss |
For each, write what you did, what happened, and how the developer should fix it. The fix is the part that proves understanding.
The permission rule
The WebGoat page says to use these techniques only for education and never to look for vulnerabilities in systems you do not have explicit permission to test. Treat that as non negotiable. If you want to test a real site, find its published security policy or program and stay within its scope.
Try it yourself
Open the demo of a web application scan and watch how a dynamic scan finds issues against a running app.
Click through it at your own pace, or open it full screen.
Quick check
Can I test my school or employer website for practice?
Not without written permission. Use a training app instead.
Do I need to be offline?
WebGoat recommends disconnecting from the internet while it runs. At minimum keep any training app bound to localhost.
Sources
Last reviewed: 19 October 2026.
