Best Vulnerable Web Apps for Pentesting Practice (2026)

Penetration testing requires legal targets. Before you can test production systems — and even after you have authorization — you need a practice environment where you can sharpen specific techniques, test payloads, confirm tool behaviour, and make mistakes without consequences.

Deliberately vulnerable web applications are the standard answer: applications intentionally built with security flaws, running on your own machine or an authorized cloud instance, designed to be attacked. This guide covers the best vulnerable web apps for penetration testing practice in 2026 — what each covers, why it matters for real engagements, and how to get it running.

What Makes a Good Vulnerable Web App for Pentesting?

Developer training apps teach you that a vulnerability exists. Pentesting practice apps should let you work the whole exploit chain — reconnaissance, payload delivery, privilege escalation, and post-exploitation — the way you would on a real engagement.

The best vulnerable web apps for pentesting have:

Realistic application architecture — not just a “vulnerable.php” file with a deliberate SQL injection, but a full application with authentication, sessions, role-based access control, APIs, file upload, and admin functionality
Multiple interconnected vulnerabilities — real engagements require chaining; a good practice app has flaws that interact
No hints or tutorials — at least in some modes; you should be able to ignore the hints and work the application on your own
Black-box accessible — you should be able to approach it the way you’d approach a real client application, without automatically having the source code
Source code available (optionally) — for verifying your findings or comparing to what a SAST scanner reports

1. OWASP Juice Shop — The Pentesting Standard

Language: Node.js/Express + Angular SPA
Best for: Realistic black-box web pentesting practice, full OWASP Top 10 coverage, modern application architecture

OWASP Juice Shop is the closest thing to a real production web application available as a deliberate target. It looks and behaves like an actual e-commerce store — a product catalog, shopping cart, user accounts, order history, admin panel, REST API, and file upload functionality. The 100+ built-in challenges cover every category you’ll encounter on a real engagement.

What makes it realistic for pentesting practice:

JWT-based authentication — the same token-based auth used by modern APIs; JWT algorithm confusion and weak secret attacks are in scope
REST API — every action has a corresponding API endpoint; the application has a full API surface to enumerate and probe
Admin interface — reaching admin functionality through access control bypass or privilege escalation is a core challenge
Real business logic — order manipulation, coupon abuse, price tampering, and workflow bypass represent real-world business logic flaws
OAuth flow — the application implements an OAuth login flow with exploitable flaws
NoSQL injection — in addition to SQL injection, Juice Shop has MongoDB-backed features with injection vulnerabilities

docker run --rm -p 3000:3000 bkimminich/juice-shop
# Application runs at http://localhost:3000/
# Register an account — no hints required
# Visit /#/score-board only if you want to see the challenge list

Black-box approach: Start without looking at the scoreboard. Use Burp Suite to proxy your browser traffic. Enumerate the API endpoints from the JavaScript source. Map the application, find the admin panel, attempt authentication bypass, and look for injection points — exactly as you would on a real engagement.

Pentesting techniques you can practice:

API endpoint enumeration from minified JavaScript
JWT modification (algorithm confusion, weak secrets, expired token reuse)
SQL injection in search and login functions
Reflected and DOM-based XSS
IDOR (accessing other users’ orders, basket contents, addresses)
Broken access control (reaching admin endpoints without admin credentials)
Insecure file upload (uploading executable files through the product review feature)
SSRF via the product image URL feature
XXE in the order XML export feature

2. DVWA — Damn Vulnerable Web Application

Language: PHP/MySQL
Best for: Systematic OWASP Top 10 drilling, technique isolation, beginner to intermediate

DVWA is the most widely used deliberate target for methodical technique practice. Each vulnerability category is isolated — you go to the SQL injection page to practice SQL injection, the XSS page to practice XSS. The three difficulty levels (Low, Medium, High) let you start with zero obfuscation and progress to filter bypass and WAF evasion.

docker run --rm -it -p 80:80 vulnerables/web-dvwa
# Visit http://localhost/ — credentials: admin / password
# Click "Create / Reset Database" before first login
# Set difficulty level via the "DVWA Security" menu

Vulnerability categories:

SQL Injection (classic, blind boolean-based, blind time-based)
Command Injection
File Upload (bypass extension filters, upload webshells)
Local and Remote File Inclusion (LFI/RFI — path traversal to /etc/passwd, log poisoning)
Cross-Site Scripting (reflected and stored)
CSRF
Brute Force
Insecure CAPTCHA
Weak Session IDs

How to use it for pentesting skill-building:

Start at Low difficulty without looking at the source code. Work each vulnerability category as a black box — craft the payload, confirm the finding, document your steps as you would in a real engagement report. Then switch to Medium difficulty and practice bypass techniques. High difficulty often requires understanding common WAF evasion patterns.

SQL injection progression on DVWA:

-- Step 1: Confirm injection exists
1'
-- Step 2: Determine number of columns
1' ORDER BY 2--
1' ORDER BY 3--  (error — only 2 columns)
-- Step 3: Find output columns
1' UNION SELECT NULL,NULL--
1' UNION SELECT 1,2--
-- Step 4: Extract database version
1' UNION SELECT @@version,2--
-- Step 5: Extract table names
1' UNION SELECT GROUP_CONCAT(table_name),2 FROM information_schema.tables WHERE table_schema=database()--
-- Step 6: Extract user credentials
1' UNION SELECT user,password FROM users--

At High difficulty, the same SQL injection exists but the input is sanitized with mysqli_real_escape_string — time-based blind injection with SLEEP() or boolean-based blind injection is required.

3. HackTheBox Web Challenges

URL: hackthebox.com
Best for: Advanced practitioners, real CVE-style vulnerability patterns, preparing for professional assessments

HackTheBox web challenges are purpose-built vulnerable applications representing real vulnerability classes found in production software — not toy examples. Each challenge is a self-contained application with a specific vulnerability (or chain of vulnerabilities) that you must identify and exploit to retrieve a flag.

Vulnerability classes in HTB web challenges:

Server-Side Template Injection (SSTI) in Jinja2, Smarty, Twig, Pebble, Freemarker, and Velocity
Insecure deserialization in PHP (object injection via unserialize()), Java (Ysoserial chains), Python (pickle), and Node.js
JWT algorithm confusion (HS256 → RS256 confusion, none algorithm, weak secret)
SQL injection in modern ORMs with unusual syntax
Server-Side Prototype Pollution (Node.js)
SSRF chained with internal service exploitation
OAuth PKCE bypass and redirect_uri manipulation
GraphQL introspection, injection, and broken access control
Race conditions in resource-limited operations
Mass assignment in REST APIs
File read via XXE with error-based or out-of-band exfiltration

Why HackTheBox for pentesting prep: HTB challenges are graded (Easy → Medium → Hard → Insane). Medium and above represent the vulnerability classes you’ll encounter in real enterprise web application assessments — logic flaws, chained vulnerabilities, non-obvious attack paths. Consistently solving Medium-rated web challenges means you’re developing skills that transfer directly to client engagements.

4. bWAPP — Buggy Web Application

Language: PHP
Best for: Maximum vulnerability breadth, covering unusual attack classes

bWAPP covers over 100 vulnerability types — more than any other single deliberately vulnerable application. It’s particularly valuable for practicing attack classes that standard training apps don’t cover.

docker run -d -p 80:80 raesene/bwapp
# Visit http://localhost/bWAPP/install.php (first run)
# Then http://localhost/bWAPP/login.php — credentials: bee / bug

Attack classes beyond OWASP Top 10 available in bWAPP:

LDAP injection
SMTP injection (email header injection)
HTML5 WebSocket attacks
iframe injection and clickjacking
Server-Side Request Forgery (SSRF)
XML injection and XXE
Unvalidated redirects and forwards
Insecure direct object references via file paths
HTTP response splitting
Client-side validation bypass (modifying JavaScript-enforced constraints)
iFrame injection for UI redressing
Heartbleed simulation
Shellshock simulation

When to use bWAPP: After you’re comfortable with the standard OWASP Top 10 in DVWA and Juice Shop, use bWAPP to broaden your coverage of attack classes. Many of the vulnerability categories you’ll encounter in real OWASP WSTG-aligned penetration tests have a corresponding bWAPP module to practice against.

5. WebGoat — Java Application Security

Language: Java/Spring
Best for: Penetration testers who focus on Java/Spring applications, Java deserialization attacks

WebGoat is OWASP’s Java-based deliberately vulnerable application. For penetration testers who regularly assess Java enterprise applications — Spring MVC, Spring Boot, Hibernate, JAX-RS APIs — WebGoat provides the right attack surface.

docker run -it -p 8080:8080 -p 9090:9090 webgoat/webgoat
# Visit http://localhost:8080/WebGoat — register to start

Pentesting techniques specific to WebGoat’s Java context:

Java deserialization via ObjectInputStream — exploiting gadget chains with ysoserial
SQL injection in JDBC and Hibernate
JWT attacks (none algorithm, algorithm confusion)
XXE in JAXB/XML parsing endpoints
Path traversal in file download endpoints
Missing function-level access control in Spring MVC

Java deserialization practice: WebGoat includes a lesson on insecure deserialization that lets you practice the conceptual attack. For generating working ysoserial payloads against real gadget chains, you’ll need to run Java applications with specific libraries — but WebGoat explains the attack class and the conditions that make exploitation possible.

6. VulnHub — Full Attack Chain Environments

URL: vulnhub.com
Best for: Full penetration test simulation (web → RCE → privilege escalation → root), OSCP preparation

VulnHub provides downloadable VMs with pre-configured vulnerable systems. Unlike the web-application-focused tools above, VulnHub machines typically include web vulnerabilities as the entry point to a full attack chain — web exploitation gets you a foothold, then you pivot to internal services, exploit local privilege escalation vulnerabilities, and ultimately gain root.

How VulnHub differs from Juice Shop and DVWA:

	Juice Shop / DVWA	VulnHub
Scope	Web application only	Full machine (web + OS + network)
Goal	Exploit specific web vulnerabilities	Root the machine
Attack chain	Single-stage	Multi-stage (web → shell → privesc → root)
Realism	High web realism	High full-engagement realism
Difficulty	Configurable	Fixed (varies by machine)

How to use VulnHub machines:

Download the OVA from vulnhub.com
Import into VirtualBox or VMware
Network the VM to host-only or NAT-only (never bridge to a real network)
Enumerate the machine IP with netdiscover or arp-scan
Run nmap -sV -sC to identify open services
Enumerate the web service, find and exploit the web vulnerability (typically LFI, SQLi, unrestricted file upload, or command injection)
Establish a foothold (reverse shell, web shell)
Enumerate the local system, identify privilege escalation vectors
Escalate to root

Recommended VulnHub machines for web pentesting:

Mr-Robot: 1 — WordPress enumeration and exploitation, file upload bypass
FristiLeaks: 1.3 — web application with authentication bypass and command injection
DC: 1 — Drupal exploitation, CVE-based web attack
Kioptrix: Level 1.1 — classic web command injection leading to root

7. PentesterLab

URL: pentesterlab.com
Best for: CVE-based exploits, code review exercises, white-box pentesting skills

PentesterLab provides vulnerability exercises based on real CVEs and vulnerability classes. Each exercise is self-contained and runs on PentesterLab’s infrastructure (no local setup required for online exercises) or can be downloaded as a VM.

What PentesterLab adds that other platforms don’t:

CVE-based exercises — exploit real vulnerabilities in real software (Shellshock, PHP-CGI RCE, Apache HTTPD traversal, serialization CVEs)
Code review exercises — you read the source code and identify the vulnerability class; this builds the white-box analysis skill critical for authenticated penetration tests
Chained exercise paths — exercises are grouped into progressive paths (Unix, Web, Whitebox) that build skills systematically

Relevant pentesting exercises (free tier):

SQLi via error-based and UNION techniques
File upload bypass (MIME type, extension, magic bytes)
Code injection in PHP eval()
JWT algorithm confusion
XXE with direct and out-of-band exfiltration
SSRF

Setting Up a Local Pentesting Lab

For realistic pentesting practice, run multiple applications simultaneously in an isolated network segment:

# Create an isolated Docker network for the lab
docker network create pentest-lab

# Run DVWA
docker run -d --name dvwa --network pentest-lab -p 8081:80 vulnerables/web-dvwa

# Run Juice Shop
docker run -d --name juiceshop --network pentest-lab -p 3000:3000 bkimminich/juice-shop

# Run bWAPP
docker run -d --name bwapp --network pentest-lab -p 8082:80 raesene/bwapp

# Run WebGoat
docker run -d --name webgoat --network pentest-lab -p 8080:8080 webgoat/webgoat

Now configure Burp Suite to proxy your browser and use the lab as a realistic multi-target environment. Practice switching between targets, maintaining separate project files for each, and documenting your findings in a structured report format.

Tools for Pentesting These Applications

These tools work well against all the deliberately vulnerable applications above:

Proxy and Interception:

Burp Suite Community/Pro — intercept, modify, and replay requests; run the active scanner (Pro) against local targets
OWASP ZAP — free, full-featured DAST scanner; excellent for automated scanning of DVWA and Juice Shop

SQL Injection:

sqlmap — automated SQL injection detection and exploitation; test against DVWA’s SQLi endpoints

sqlmap -u "http://localhost/vulnerabilities/sqli/?id=1&Submit=Submit" \
  --cookie="PHPSESSID=your_session_id; security=low" \
  --dbs --batch

Fuzzing:

ffuf — fast web fuzzer for endpoint enumeration, parameter fuzzing, content discovery
wfuzz — web application fuzzer for parameter and header fuzzing

Password Attacks:

Hydra — online password bruteforce; test DVWA’s brute force protection
John the Ripper / Hashcat — offline hash cracking after extracting hashes from DVWA’s database via SQLi

Payload Databases:

PayloadsAllTheThings (GitHub) — comprehensive payload lists for all injection types
SecLists — wordlists for enumeration, fuzzing, and password attacks

Building a Pentesting Methodology with Vulnerable Apps

Use deliberately vulnerable web apps to build and validate a consistent penetration testing methodology before applying it on real engagements. Here’s a repeatable approach for each target:

Phase 1: Reconnaissance

# Identify the application and its technology stack
curl -I http://localhost:3000/ | grep -i server
curl -I http://localhost:3000/ | grep -i x-powered-by

# Enumerate content (directories, files, endpoints)
ffuf -u http://localhost:3000/FUZZ -w /usr/share/seclists/Discovery/Web-Content/common.txt

# Identify all API endpoints (for Juice Shop — extract from JavaScript)
# Look in /main.js and /vendor.js for route definitions

Phase 2: Authentication Testing

# Test for default credentials
# Test for username enumeration via different error messages
# Test for account lockout (or lack thereof)
# Test session token entropy and predictability
# Test password reset flow for bypass

# For DVWA brute force
hydra -l admin -P /usr/share/wordlists/rockyou.txt \
  http-post-form "localhost/vulnerabilities/brute/:username=^USER^&password=^PASS^&Login=Login:Username and/or password incorrect." -V

Phase 3: Input Validation Testing

# SQL injection probe
' OR '1'='1
' OR 1=1--
' UNION SELECT NULL--

# XSS probe
<script>alert(1)</script>
"><script>alert(1)</script>
'><img src=x onerror=alert(1)>

# Command injection probe
; id
| id
&& id
`id`

# Path traversal probe
../../etc/passwd
....//....//etc/passwd
%2e%2e%2fetc%2fpasswd

Phase 4: Authorization Testing

# Horizontal privilege escalation — change user IDs in requests
# Example: Juice Shop — access another user's orders
curl -H "Authorization: Bearer YOUR_JWT" \
  http://localhost:3000/api/Users/2  # Change the ID

# Vertical privilege escalation — access admin endpoints without admin role
curl -H "Authorization: Bearer YOUR_JWT" \
  http://localhost:3000/api/Users/    # Admin-only endpoint

Phase 5: Reporting

Document every finding with:

Vulnerability name and CWE/CVE reference
Evidence — the request and response demonstrating the vulnerability
Risk rating — Critical/High/Medium/Low/Informational with business justification
Remediation — specific fix recommendation

Practice writing this documentation against deliberately vulnerable apps so the process is smooth on paid engagements.

Moving From Practice to Real Engagements

Deliberately vulnerable web apps build the skills and technique muscle memory. For real production applications:

Always have written authorization — a scope document signed by the application owner before any testing begins
Define scope precisely — which domains, which environments (test vs. production), which IP ranges
Use a dedicated testing environment when possible — avoid testing production directly
Maintain an activity log — timestamps and actions taken, in case testing causes unintended effects
Establish a communication channel with the application team — know who to contact if you accidentally cause an outage

Offensive360 provides both SAST and DAST scanning as an alternative or complement to manual pentesting. SAST finds code-level vulnerabilities (including complex injection patterns and second-order attacks) before the application is deployed. DAST runs authenticated scans against your running application, finding the same vulnerability classes you’d find in a manual pentest — at scale and without human-hours limitations.

Frequently Asked Questions

Is it legal to use these apps for pentesting practice?

Yes — when you run them locally in Docker or on a private VM. All of these applications are explicitly built and licensed for security testing practice. Never deploy them on a public server or test them from a network where other people could access them. Always run them in an isolated, private environment.

Which app is best for a pentesting beginner?

Start with DVWA at Low difficulty — the isolated vulnerability categories and code viewer make it the best learning environment. Once you can exploit all categories reliably, move to OWASP Juice Shop for a realistic black-box experience that more closely resembles a real web application pentest.

Can I use these apps to prepare for OSCP?

Vulnerable web applications are useful supplementary OSCP preparation for web exploitation modules. OSCP focuses primarily on network exploitation, buffer overflows, Active Directory, and privilege escalation chains. For the web components specifically, DVWA, Juice Shop, and VulnHub VMs (particularly those with web-to-root chains) are all relevant practice. The TJ Null OSCP prep list is the community-curated starting point for machine selection.

Can I use Burp Suite against these applications?

Yes — all Docker-based applications work seamlessly with Burp Suite. Configure your browser to use Burp as a proxy (127.0.0.1:8080 by default). Burp will intercept all traffic between your browser and the application, allowing you to inspect, modify, and replay requests. For Juice Shop, this is particularly powerful because the application’s entire API surface becomes visible and explorable through the Burp proxy history.

What’s the difference between a DAST scanner and manual pentesting against these apps?

A DAST scanner like Offensive360’s automated scanner systematically covers the application’s entire surface — every endpoint, every parameter — with a broad set of attack payloads, in a fraction of the time manual testing requires. Manual pentesting excels at business logic flaws, multi-step attack chains, and vulnerabilities that require human judgment to identify.

Using both is the most effective approach: run DAST first to identify and confirm the high-confidence findings, then apply manual techniques to the areas DAST flags as interesting and to test business logic that automated tools can’t reason about.

Next Steps

After practicing on deliberately vulnerable web apps:

See how Offensive360 SAST finds vulnerabilities in source code — the same SQL injection, XSS, and command injection patterns you exploit in DVWA exist in production codebases
Run a DAST scan on your web application — see what an automated scanner finds against your real application, not just a practice target
Book a demo — see Offensive360 scan a deliberately vulnerable application live, then against real-world code