What is DVWA and why use it in a home lab?

DVWA (Damn Vulnerable Web Application) is a PHP/MariaDB app deliberately riddled with the kinds of bugs covered in the OWASP Top 10 - SQL injection, broken access control, XSS, and more. It gives a home lab a legal, disposable target built specifically so you can practice finding and fixing these bugs without breaking any law or anyone else's system.

What do the DVWA difficulty levels mean?

DVWA Security sets how obvious each bug is: Low is for your first pass at each vulnerability class, Medium removes the point where basic payloads stop working so you must think about filter bypass, and High approximates a closer-to-real, partially-hardened application. Working through Low on every module first builds a mental model of the bug class rather than a lucky working payload.

LAB · WALKTHROUGH

Add a vulnerable target to your lab.

Q: What is the fastest way to run DVWA?

The community vulnerables/web-dvwa Docker image gets DVWA running in one line: docker run --rm -it -p 8080:80 vulnerables/web-dvwa. Point a browser on the same host at http://localhost:8080 and log in with the default credentials admin / password.

Q: How do I reset DVWA to a clean state between practice sessions?

If you used the one-line docker run --rm command, stopping the container deletes it automatically. If you used Docker Compose, docker compose down stops and removes the containers, and adding -v also wipes the database volume - giving a clean, known-vulnerable starting state every time with no half-fixed bug carried over from a previous session.

A lab with nothing to attack is just a VM. DVWA in Docker gives you a legal, disposable target in one command — and one rule that keeps it that way.

July 5, 202610 min read

If you followed building a home lab on one laptop, you now have an isolated network and a place to work. What's missing is something to actually practice against. DVWA (Damn Vulnerable Web Application) is the standard answer: a PHP/MariaDB app that's deliberately riddled with the kinds of bugs covered in the OWASP Top 10 — SQL injection, broken access control, XSS, and more — built specifically so you can practice finding and fixing them without breaking any law or anyone else's system.

Read this before you do anything else. DVWA is intentionally broken. Never run it on a public IP, a shared network, or any hosting provider's public folder — the project's own documentation warns it will be compromised within hours if you do. Everything below assumes the isolated lab network from the previous walkthrough: host-only or NAT, no port forwarding, no exposure beyond your own machine.

The fastest path: one command

The official repository ships a Docker Compose setup, but if you just want it running right now, the community vulnerables/web-dvwa image gets you there in a single line:

docker run --rm -it -p 8080:80 vulnerables/web-dvwa

Point a browser on the same host at http://localhost:8080, and you'll land on DVWA's setup screen. Default credentials are admin / password — change them if you're going to leave this running for more than a single session, even inside an isolated lab.

The official way, if you want it to persist

For a setup that survives a reboot and matches what the maintainers actually test against, clone the official repo and use its Compose file instead of a one-off container:

git clone https://github.com/digininja/DVWA.git
cd DVWA
docker compose up -d

This brings up DVWA and its MariaDB backend together, available at http://localhost:4280 by default. Because every commit to the project's master branch rebuilds the image automatically, this route also tends to be more current than pinning to an older community image.

Setting the difficulty

After logging in, DVWA Security sets how obvious the bugs are:

Level	When to use it
Low	Your first pass at each vulnerability class
Medium	Once basic payloads stop working and you need to think about filter bypass
High	Once you want something closer to a real, partially-hardened application

Work through Low on every module first — the point is building a mental model of each bug class, not stumbling into a working payload by luck.

What to actually practice

Don't just click through every module once. Pick two or three that map to categories you're weak on, and go deep: try SQL Injection at Low, then Medium, and notice exactly which input sanitization change breaks your first payload and what you had to adjust. Repeat for Command Injection and stored XSS. That comparison — what changed between difficulty levels — teaches you more about how filters actually fail than the vulnerability itself does.

Two modules worth extra time: File Upload, because it's the module that most directly demonstrates how "we validate file types" so often means "we checked the extension" — bypassing that at Medium and High teaches a lesson that shows up constantly in real applications. And Brute Force, because it's the module where you'll actually reach for a tool like Burp Suite or a scripted request loop instead of a browser, which is a useful bridge if the Burp vs. ZAP comparison is still theoretical to you.

Cleaning up

Because DVWA is disposable by design, treat it that way. If you used the one-line docker run command with --rm, stopping the container (Ctrl+C, or docker stop from another terminal) deletes it automatically — nothing lingers. If you used Docker Compose, docker compose down stops and removes the containers, and adding -v also wipes the database volume, which is exactly what you want between practice sessions: a clean, known-vulnerable starting state every time, with no half-fixed bug carried over from last week.

A note on scope. This walkthrough is for practicing on infrastructure you own, in an isolated environment, for defensive and educational purposes. The same rule that applies to every tool covered on this site applies here: never point these techniques at a system you don't own or don't have explicit written authorization to test.

This is the pattern worth keeping: a disposable target, a throwaway environment, and a way to reset both in one command. Once DVWA stops teaching you anything new, the same approach — pull a container, break it, tear it down — applies to the next intentionally vulnerable app you add to the same lab.