DVWA Tutorial: Setup and Walkthrough for Beginners (2026)

What Is DVWA?

DVWA (Damn Vulnerable Web Application) is a PHP and MariaDB web application built to be insecure on purpose, so that students, developers and penetration testers can practice attacking real vulnerabilities legally on their own hardware. It was written by Ryan Dewhurst in 2008 and is now maintained by Robin Wood (digininja) on GitHub, free and open source under GPLv3.

The current release is version 2.5, published in January 2025, which added a module for vulnerable OpenAPI endpoints. The official repository ships 19 vulnerability modules covering SQL injection, blind SQL injection, command injection, reflected, stored and DOM-based XSS, CSRF, file inclusion, file upload, brute force, weak session IDs, authorization bypass, broken access control, Content Security Policy bypass, JavaScript logic, open redirect, insecure CAPTCHA, cryptography and the API playground.

Two design decisions make it better for learning than most vulnerable apps. First, every page has a View Source button that shows the exact PHP handling your input, so you can see why your payload worked instead of guessing. Second, each module exists at four difficulty levels, so the same vulnerability teaches you filter evasion and then teaches you the fix.

It is listed in the OWASP Vulnerable Web Applications Directory and ships as a package in Kali Linux, which is a reasonable signal that it is the community standard rather than a random GitHub project.

How to Install DVWA With Docker

Docker is the right choice for a first install. The manual route means installing Apache, PHP and MariaDB, editing php.ini, fixing folder permissions and then debugging whatever your distro did differently. The container route is four commands.

1. Check Docker is present. Run docker version and docker compose version. Both need to return a version number. Docker Desktop includes Compose already; on Linux, install Docker Engine from the official repository rather than your package manager, which tends to ship an older Compose.
2. Clone the repository. git clone https://github.com/digininja/DVWA.git then cd DVWA. Use the official repo. The mirrors floating around SourceForge and Docker Hub are years behind and missing modules.
3. Start it. docker compose up -d. The first run pulls the prebuilt image from GitHub Container Registry and takes a minute or two.
4. Open it. Browse to http://localhost:4280. The container listens on 4280, not 80, which is the single most common reason people think the install failed.

On Kali, sudo apt install dvwa gets you the packaged version, documented on the Kali tools page. It works, but it lags the GitHub release, so you may be missing the newest modules. If you want to install by hand on Debian or Ubuntu you need apache2, libapache2-mod-php, mariadb-server, mariadb-client, php, php-mysqli and php-gd, with PHP 7.3 as the hard minimum.

First Login and Database Setup

The login page asks for credentials before you have created any. The DVWA default login is username admin and password password. The README notes, with visible amusement, that these can easily be brute forced. That is not an accident, it is the Brute Force module hinting at itself.

Once you are in, the app will complain that the database does not exist. Click Setup DVWA in the left menu, scroll to the bottom, and click Create / Reset Database. You get logged out, you log back in, and the five sample users are now in place. Come back to this button whenever a module starts behaving oddly, because half the "DVWA is broken" questions on forums are solved by resetting the database.

The setup page also runs a checklist of your PHP configuration. Two entries matter early:

• allow_url_include needs to be on for the Remote File Inclusion half of the file inclusion module. On the Docker image it already is. On a manual install you will be editing /etc/php/8.x/apache2/php.ini and restarting Apache.
• reCAPTCHA keys are only needed for the Insecure CAPTCHA module. Skip that module for now and ignore the warning. It is the one lab that requires an external account, and it teaches less than the others.

In practice, the fastest way to lose an hour on a fresh install is the writable uploads directory. The File Upload module writes into ./hackable/uploads/, and if the web server user cannot write there, uploads silently fail in a way that looks like a filter blocking you. The Docker image handles this. A manual install does not always.

The Four Security Levels Are the Actual Curriculum

The DVWA Security page lets you set the level to Low, Medium, High or Impossible, and this is where most beginners waste the tool. They set it to Low, clear ten modules in an evening, and conclude they know web hacking. Low is a tutorial, not a lab.

Impossible is the level people ignore, and it is the one that makes you employable. Reading it after you have broken the other three is the closest thing to a free lesson in secure development. A report that says "you are vulnerable to SQL injection" is worth something. A report that shows the parameterized query that fixes it is worth considerably more.

Walkthrough: SQL Injection From Low to Impossible

The SQL Injection module gives you a box that takes a User ID and returns a name. At Low, the source is a single line of string concatenation:

$query = "SELECT first_name, last_name FROM users WHERE user_id = '$id';";

Your input lands inside single quotes with no escaping, so the first job is to break out of the quote. Enter 1' OR '1'='1 and the condition becomes always true, returning all five users instead of one. That is your proof the injection point exists.

Now make it useful. The query returns two columns, so a UNION needs to return two columns as well:

1' UNION SELECT user, password FROM users#

The output now lists every username alongside an MD5 hash of their password. The trailing # comments out the rest of the original query, including its closing quote. If you want the theory behind why the column count has to match, our SQL injection tutorial works through UNION attacks step by step.

Move to Medium and the input box becomes a dropdown. This is a client-side restriction, which means it is not a restriction at all. Intercept the request in a proxy, or just resubmit it with a modified id parameter, and you are back in business. Medium also switches to mysqli_real_escape_string and drops the surrounding quotes, so the payload changes shape: no quote to escape, and 1 OR 1=1 works directly.

Then read Impossible, which is the actual point of the exercise:

if( is_numeric( $id ) ) {
    $id = intval( $id );
    $data = $db->prepare( 'SELECT first_name, last_name FROM users WHERE user_id = (:id) LIMIT 1;' );
    $data->bindParam( ':id', $id, PDO::PARAM_INT );
    $data->execute();
}

Four defenses stacked: a type check, an integer cast, a prepared statement with a bound parameter, and a row limit. There is also an anti-CSRF token on the form. Nothing you type reaches the SQL parser as code, which is why no payload works and why this is the pattern to copy.

Walkthrough: Command Injection, XSS and File Upload

These three modules are where DVWA earns its reputation, because each one has a Medium or High level with a genuinely instructive gap in the filter.

Command Injection

The page pings an IP address you supply. At Low, the code is shell_exec( 'ping -c 4 ' . $target ), so anything you append runs on the host. Try 127.0.0.1; whoami and the ping output arrives with www-data underneath it.

Medium adds a blacklist that deletes && and ; from your input. That is two shell separators removed out of at least five. A pipe still works:

127.0.0.1 | whoami

High extends the blacklist to ||, &, ;, -, $, (, ), backtick, and | followed by a space. Read that last entry again. The filter removes a pipe with a trailing space, and leaves a bare pipe alone. So 127.0.0.1|whoami walks straight through.

That one character is the most valuable lesson in the whole application. Blacklists fail on the case the author did not picture, and finding that case is the job. The OWASP command injection reference lists the separators worth testing systematically rather than by guesswork.

Reflected XSS

At Low, your name parameter is echoed straight into the page, so <script>alert(1)</script> fires immediately. Medium is more interesting. The filter is:

$name = str_replace( '<script>', '', $_GET[ 'name' ] );

One string, removed once, case sensitive. Three separate ways past it, and each teaches a different habit. Change the case with <SCRIPT>alert(1)</SCRIPT>. Nest the tag so removing the inner one rebuilds the outer one, using <scr<script>ipt>alert(1)</script>. Or avoid the word entirely with <img src=x onerror=alert(1)>, which is the payload that keeps working long after the other two stop.

File Upload

Low accepts any file and drops it in hackable/uploads/. Upload a small PHP file that runs a command from a query parameter, browse to the path the page prints back at you, and you have code execution.

Medium checks two things: that the size is under 100000 bytes and that the MIME type is image/jpeg or image/png. The size is real. The MIME type is not, because it comes from the Content-Type header that your browser sends and that you fully control. Intercept the upload, change Content-Type: application/x-php to Content-Type: image/jpeg, forward it, and the PHP file lands intact. Our Burp Suite tutorial covers the intercept and modify workflow if you have not set up a proxy yet.

The general rule this module is teaching: any value the client sends is a suggestion, never a fact. Filename, extension, Content-Type, hidden form fields, cookies. All of it is attacker controlled.

The Modules Beginners Skip

Everyone does SQL injection and XSS. Three modules get ignored and they are the ones that map most directly to paid work.

• Blind SQL Injection. Same vulnerability, no error messages and no visible output. You confirm it with a boolean condition or a time delay and extract data one character at a time. Slower, less satisfying, and far closer to what real applications look like once error reporting is switched off in production.
• Weak Session IDs. Click the button, watch the cookie, notice it increments by one. Predictable session identifiers let you become another user without touching their password. It takes ten minutes and it changes how you look at every cookie afterwards.
• File Inclusion. At Medium the filter strips ../ and ..\ once, so ....// collapses back into ../ after the replacement runs. It also strips http://, which hthttp://tp:// defeats the same way. Doubling up your payload to survive a single-pass filter is a pattern you will reuse constantly.

A practical habit worth forming: after you solve a module at Low, do not move to the next module. Move to Medium on the same one. Depth on a single vulnerability class beats breadth across ten of them, especially when the source code for the fix is one click away.

What DVWA Will Not Teach You

DVWA is excellent at one job and mediocre at several others. Being honest about the gap saves you from the plateau that catches a lot of self-taught people.

It has no reconnaissance phase. Every vulnerability is labeled, in a menu, with a button. Real testing starts with a domain and a lot of uncertainty, and finding the vulnerable parameter is most of the work. DVWA hands you that parameter for free.

The stack is dated. It is server-rendered PHP with query strings and form posts. That teaches the fundamentals honestly, and the fundamentals still hold. It teaches you nothing about a React front end talking to a JSON API, JWT handling, GraphQL, or the authorization logic bugs that dominate modern bug bounty reports.

Nothing pushes back. No rate limiting, no WAF, no logging, no lockout. Useful while you are learning the payload. Misleading about how an engagement actually feels.

None of that makes it a bad first target. It makes it a first target. Use it to learn what each vulnerability class looks like from the inside, then move to environments where you have to find the bug before you can exploit it. OWASP Juice Shop, a hosted lab platform, or a live bug bounty program are all reasonable next stops.

Legal and Ethical Considerations

• Keep it local. Bind it to localhost or a NAT-mode VM. An exposed DVWA is a working backdoor into your own network, and automated scanners find one within hours.
• Do not reuse the payloads casually. Typing 1' OR '1'='1 into a login form you do not own is unauthorised access under the Computer Misuse Act in the UK, the CFAA in the US, and equivalent legislation almost everywhere else.
• Bug bounty programs are the legal route. They give you written permission and a defined scope. Read the scope before you test, not after.
• Report what you find responsibly. If you stumble across a real vulnerability outside a program, disclose it to the owner and stop testing. Do not pull data to prove your point.

Frequently Asked Questions