There’s a persistent myth among people learning offensive security that the fastest way to get good is to poke at real, live websites and “see what happens.” It’s a fast way to get good, all right, at explaining yourself to a magistrate. In most jurisdictions, running a vulnerability scanner or attempting SQL injection against a system you don’t own or have written permission to test is a criminal act, regardless of whether you cause any damage or ever intended harm. Curiosity is not a legal defense.
The good news is that you never need to break that line. The security community has built an entire ecosystem of intentionally broken applications and sanctioned target ranges whose whole purpose is to be attacked. These give you the same SQL injection, cross-site scripting, broken authentication, and misconfigured servers you’d find in the wild, but with an explicit invitation to exploit them. This article explains what these training targets are, how they differ, and where to find the ones worth your time.
What “Deliberately Vulnerable” Actually Means
A deliberately vulnerable website is an application built or configured to contain known, exploitable flaws on purpose. Unlike a real production app, where a bug is an accident someone will eventually patch, these flaws are the feature. They exist so you can find them, exploit them, understand the underlying mechanism, and learn how to fix them, all without touching anyone else’s data or infrastructure.
They generally come in a few flavors:
- Self-hosted vulnerable apps. You download a package (often a Docker image or a virtual machine), run it on your own laptop, and attack it entirely inside your network. Nothing you do ever leaves your machine, so there is zero legal exposure. DVWA, OWASP Juice Shop, and bWAPP are classic examples.
- Hosted labs and ranges. A provider stands up vulnerable machines in the cloud and gives you authorized access through a VPN or browser. You get variety and infrastructure you couldn’t easily build yourself, in exchange for staying inside their scope. Hack The Box and TryHackMe are the well-known ones.
- Public “hack me” targets. A handful of sites are permanently online with standing permission to be attacked, precisely so people have a safe URL to point tools at. These are the exception to the “never scan what you don’t own” rule, and only because the owner has published that permission.
The critical distinction is legal, not technical. What makes a target safe isn’t that it’s easy or educational; it’s that someone with authority over it has given you explicit consent to attack it.
Targets Worth Your Time
You don’t need dozens of these. A small, well-chosen set will carry you from your first injection to reasonably advanced work.
OWASP Juice Shop is probably the best modern starting point. It’s a realistic single-page JavaScript storefront riddled with vulnerabilities mapped to the OWASP Top 10, structured as a set of challenges with a built-in scoreboard. It’s actively maintained and teaches how bugs look in a real, contemporary web stack rather than a decade-old PHP app.
DVWA (Damn Vulnerable Web Application) is the old reliable. It’s a compact PHP/MySQL app with adjustable security levels (low, medium, high, impossible), so you can watch the same attack succeed against weak code and then get blocked by a proper fix. That before-and-after view is genuinely instructive.
bWAPP and the OWASP WebGoat project fill similar niches, with WebGoat leaning heavily into guided lessons that walk you through the theory alongside the exploitation.
For infrastructure and full-machine work rather than just web apps, Hack The Box and TryHackMe are the standards. TryHackMe is more beginner-friendly with structured learning paths; Hack The Box throws you at boxes with less hand-holding. Both are authorized environments, so the machines are fair game inside their platforms.
Two long-standing public sites deserve a mention because they exist specifically to be scanned and attacked:
scanme.nmap.orgis maintained by the Nmap project as a legal target for practicing port scans.testphp.vulnweb.com(and its sibling test sites) are published deliberately vulnerable web apps you’re permitted to test.
Always confirm the current terms on the site itself before you point anything at it, because standing permission can change.
Getting Hands-On: A Quick Walkthrough
The fastest way to a working lab is Docker. Juice Shop, for instance, is a single command:
# Pull and run OWASP Juice Shop, exposing it on localhost:3000
docker run -d -p 3000:3000 bkimminich/juice-shopThe -d runs it detached in the background, and -p 3000:3000 maps the container’s port to your machine so you can browse to http://localhost:3000. Everything stays local.
With a target running, reconnaissance comes first. Against a legal scanning host, a basic Nmap sweep looks like this:
# Service/version detection on the Nmap project's sanctioned target
nmap -sV -T4 scanme.nmap.org-sV probes open ports to identify the service and version behind them (banner grabbing), and -T4 speeds up timing on a responsive host. That version information is exactly what an attacker uses to match a service against known CVEs.
For web-layer work, curl is enough to demonstrate a classic reflected input issue. Against a deliberately vulnerable test app, a probe for SQL injection might start as simply as:
# Testing how a parameter reacts to an injected quote
curl "http://testphp.vulnweb.com/artists.php?artist=1'"If the response returns a database error rather than a clean page, the parameter is likely concatenating your input straight into a SQL query, the hallmark of an injectable field. From there you’d move to a purpose-built tool rather than crafting payloads by hand:
# Let sqlmap enumerate the injection automatically
sqlmap -u "http://testphp.vulnweb.com/artists.php?artist=1" --batch --dbs--batch accepts sqlmap’s default prompts non-interactively, and --dbs asks it to enumerate the available databases once it confirms the flaw. Running this against anything other than a site that has invited it is where curiosity becomes a crime, so keep it pointed at sanctioned targets only.
Building Good Habits Early
Treat every practice session the way a professional treats a paid engagement. Define your scope before you start and stay inside it, even in a lab, because scope discipline is a muscle you want trained by the time real client systems are involved. Keep notes as you go: what you tried, what worked, and why the vulnerability existed. The point of these platforms isn’t to rack up captured flags; it’s to internalize the mechanism so you recognize the same class of bug in an unfamiliar codebase later.
It’s also worth pairing every exploit you learn with its remediation. Knowing that parameterized queries kill SQL injection, that output encoding stops most XSS, and that proper session handling defeats a whole family of authentication bugs is what turns a “hacker” into a security engineer whom organizations actually want to hire.
The Takeaway
The line between a security researcher and a defendant is consent, not skill or intent. Deliberately vulnerable websites exist so you never have to gamble with that line: they hand you real, exploitable flaws with permission attached, letting you build genuine attack and defense experience in an environment where the worst-case outcome is a container you delete and rebuild. Start local with something like Juice Shop or DVWA, graduate to authorized ranges like TryHackMe and Hack The Box as your confidence grows, and reserve any live scanning for the small set of hosts that publicly invite it. Master the craft in the sandbox, and you’ll be ready for the real thing without ever having risked crossing into it uninvited.