Unlock cybersecurity expertise, protect digital frontiers, secure your future today! Join Now
Home
Cyber Security

How to Set Up Damn Vulnerable Web Application (DVWA) on Kali Linux

DVWA is a vulnerable PHP/MySQL web app for learning web security, testing exploits like SQLi, XSS, and CSRF in a safe local environment

How to Set Up Damn Vulnerable Web Application (DVWA) on Kali Linux

Damn Vulnerable Web Application (DVWA) is a deliberately insecure PHP/MySQL web application designed for learning and practicing common web vulnerabilities. Its purpose is to help security professionals, developers, and students safely explore vulnerabilities like SQL injection, XSS, CSRF, and more. Important: DVWA is intentionally vulnerable. Never deploy it on any internet-facing server or production environment. Instead, use it in a controlled environment such as a Kali Linux virtual machine with NAT networking. This guide explains, step-by-step, how to install and configure DVWA on Kali Linux, covering prerequisites, installation of required packages, cloning the DVWA repository, configuring Apache/PHP, setting up the database, adjusting file permissions, and exploring DVWA’s security levels and modules. We also cover using tools like Burp Suite and OWASP ZAP with DVWA, common troubleshooting fixes, and an optional Docker-based setup.

Prerequisites and System Requirements

Before installing DVWA, ensure your system meets the following requirements:

  • Operating System: A Debian-based OS, such as Kali Linux (latest version recommended). DVWA is explicitly tested on Debian-based systems.
  • Hardware: DVWA itself is lightweight, but Kali (with GUI and browsers) may require ~2 GB RAM or more. A VM with at least 2 GB RAM and 20 GB disk is typical.
  • Isolation: For safety, run Kali (and DVWA) in a virtual machine or isolated container. DVWA’s maintainers strongly advise using a VM (e.g. VirtualBox, VMware) in NAT mode to avoid exposing vulnerabilities to your network.
  • Network: Internet access (to download packages and clone repositories). You should also have a web browser inside Kali.
  • Privileges: Ability to use sudo or root on Kali, since we will install system packages and modify web server files.

Security Caution: DVWA is highly insecure by design. Keep the following in mind:

  • Do not expose DVWA to the public internet. Only access it locally (e.g. http://127.0.0.1/dvwa) on your Kali machine.
  • Use strong passwords for any accounts, since DVWA may contain hard-coded credentials (e.g. default “admin/password” login). Change these in practice.
  • Run regular system updates on Kali, but avoid installing unnecessary services. This minimizes extraneous vulnerabilities.

In summary, DVWA requires Apache, MySQL/MariaDB, and PHP on a Kali Linux host. We will install these prerequisites below.

Installing Required Software Packages

On Kali Linux, most DVWA dependencies are available via apt. Open a terminal and update the package list:

sudo apt update

Then install Apache2 (the web server), MariaDB (a MySQL-compatible database server), PHP (along with required extensions), and Git (to clone DVWA):

sudo apt install -y apache2 mariadb-server mariadb-client php php-mysqli php-gd libapache2-mod-php git

This command installs:

  • apache2: The Apache web server.
  • mariadb-server, mariadb-client: The MariaDB database server and client (a drop-in replacement for MySQL). DVWA works with MySQL too, but MariaDB is recommended as it “works out of the box”.
  • php, php-mysqli, libapache2-mod-php: PHP runtime and Apache PHP module (to process PHP pages). The php-mysqli extension allows PHP to connect to MySQL/MariaDB.
  • php-gd: PHP image processing library (used by some DVWA components).
  • git: To clone the DVWA repository from GitHub.

These packages cover the essentials. During installation, you may be asked to set a MariaDB root password (or you can leave it blank and secure it later). For simplicity, you can set a strong root password when prompted, or leave it default and use sudo mysql to connect without a password (MariaDB often allows the “unix_socket” method on Debian). If you install MariaDB, ensure it starts up:

sudo systemctl enable --now mariadb
sudo systemctl enable --now apache2

These commands enable and start the MariaDB and Apache services. Verify they are running:

sudo systemctl status mariadb
sudo systemctl status apache2

Alternatively, you can install DVWA via Kali’s repository with one command (this is an automated Kali package):

sudo apt install dvwa

This will fetch DVWA and its dependencies automatically. After installation, you can run dvwa-start (a helper script) to start DVWA’s services. However, this guide focuses on the manual approach, as it provides more insight into each step.

Cloning DVWA from the GitHub Repository

Once the server environment is ready, we fetch the DVWA code. By default, Apache on Debian-based systems serves files from /var/www/html/. We’ll place DVWA there.

Open a terminal and navigate to the web root:

cd /var/www/html/

Clone the DVWA GitHub repository into a subdirectory named dvwa:

sudo git clone https://github.com/digininja/DVWA.git dvwa

This command creates /var/www/html/dvwa/ containing all DVWA files. You can verify the files:

ls /var/www/html/dvwa/

You should see DVWA PHP files and directories (like vulnerabilities/, config/, etc.).

Security note: DVWA’s code is intentionally vulnerable and should be kept offline. GitHub’s official repository has warnings: “Damn Vulnerable Web Application is damn vulnerable! Do not upload it to your hosting provider’s public html folder or any Internet facing servers, as they will be compromised”.

Configuring Apache and PHP for DVWA

Now configure Apache and PHP so that DVWA works correctly.

Copying the DVWA Configuration File

DVWA ships with a sample database configuration file. We need to copy and edit it. In the DVWA folder:

cd /var/www/html/dvwa/config/
sudo cp config.inc.php.dist config.inc.php

This creates config.inc.php from the template. Next, edit this file to set database credentials and other options:

sudo nano config.inc.php

Find the database settings section and ensure they match what we plan to use. For example:

$_DVWA = array();
$_DVWA['db_server']   = '127.0.0.1';      // MySQL server address
$_DVWA['db_database'] = 'dvwa';           // Database name
$_DVWA['db_user']     = 'dvwa';           // Database username
$_DVWA['db_password'] = 'p@ssw0rd';       // Database password
$_DVWA['db_port']     = '3306';           // MySQL port

These values should match the database and user you will create (see next section). Also verify the default security level:

$_DVWA['default_security_level'] = 'low';  // Default security level (low/medium/high/impossible)

By default, DVWA uses low security, which has minimal filtering. You can later change this from the DVWA interface. Save and exit the editor (in nano, press Ctrl+O then Ctrl+X).

PHP Configuration Adjustments

DVWA requires a couple PHP settings for certain labs:

  • allow_url_include = On and allow_url_fopen = On: Enables remote file inclusion (RFI) functionality.
  • display_errors = On: To see PHP errors (helps in debugging/troubleshooting).

Open the PHP configuration for Apache. The path may vary depending on PHP version. For example, if using PHP 8.4:

sudo nano /etc/php/8.4/apache2/php.ini

If you have a different PHP version (e.g. 8.2 or 7.4), adjust the path accordingly. Inside php.ini, enable or adjust the following lines:

allow_url_fopen = On
allow_url_include = On
display_errors = On
display_startup_errors = On

Typically, they are commented or set to Off by default. Make sure to remove any semicolons (;) and set them to On. For example, change allow_url_include = Off to allow_url_include = On. Save and exit the editor.

Also, ensure Apache’s mod_rewrite module is enabled (DVWA’s API module uses it). Enable it with:

sudo a2enmod rewrite

After changes, restart Apache to apply:

sudo systemctl restart apache2

We’ve now prepared Apache and PHP. DVWA’s files should be served correctly by Apache.

Creating and Securing the DVWA Database in MariaDB/MySQL

DVWA needs a database to store user accounts and logs. We will create a database and a dedicated user for DVWA.

Starting the Database Service

First, make sure the database server is running:

sudo systemctl start mariadb

(or sudo service mysql start if MariaDB is aliased as mysql).

Optionally run the secure installation script to set the root password and secure MariaDB:

sudo mysql_secure_installation

Follow prompts to remove anonymous users, disallow remote root login, and set a strong root password. Once done, log in to MariaDB as root:

sudo mysql -u root -p

Enter the MariaDB root password you set (or leave blank if none).

Creating the DVWA Database and User

At the MariaDB prompt, create a database named dvwa:

CREATE DATABASE dvwa;

Then create a database user (we will use dvwa as the username) and grant it privileges on the dvwa database. Use the same credentials you placed in config.inc.php. For example:

CREATE USER 'dvwa'@'127.0.0.1' IDENTIFIED BY 'p@ssw0rd';
GRANT ALL PRIVILEGES ON dvwa.* TO 'dvwa'@'127.0.0.1';
FLUSH PRIVILEGES;

These commands do the following:

  • CREATE USER 'dvwa'@'127.0.0.1' IDENTIFIED BY 'p@ssw0rd'; – creates a new MariaDB user dvwa that can connect from localhost, with password p@ssw0rd.
  • GRANT ALL PRIVILEGES ON dvwa.* TO 'dvwa'@'127.0.0.1'; – grants all privileges on the dvwa database to this user.
  • FLUSH PRIVILEGES; – reloads the grant tables so changes take effect.

Note: Some tutorials use 'dvwa'@'localhost' instead of '127.0.0.1'; either works if consistent with db_server in config.inc.php. We used 127.0.0.1 above to match the config file setting. If you used localhost, create the user with 'dvwa'@'localhost'. The DVWA docs also demonstrate creating dvwa@localhost.

You can verify the database exists:

SHOW DATABASES;

And check users:

SELECT User, Host FROM mysql.user;

Exit the MariaDB shell:

exit

Now the database and user are ready. DVWA’s setup script (next) will populate it with tables.

Setting Proper File Permissions

DVWA’s files need the correct permissions and ownership so that Apache (the www-data user on Debian/Kali) can read and write as needed. In particular, DVWA’s “file upload” lab requires write access to the upload directory.

Return to the shell and adjust permissions:

sudo chown -R www-data:www-data /var/www/html/dvwa
sudo chmod -R 755 /var/www/html/dvwa

Explanation:

  • chown -R www-data:www-data /var/www/html/dvwa: makes the www-data user and group the owner of all DVWA files. Apache runs as www-data on Debian/Kali, so this ensures it can read and write these files.
  • chmod -R 755 /var/www/html/dvwa: gives owner full access, and group/others read+execute. This is more secure than 777. It should suffice for DVWA operation.

Specifically, for the file upload vulnerability, the hackable/uploads/ directory must be writable by the web server. The above chown ensures that. If any upload errors occur, make sure:

sudo chmod 775 /var/www/html/dvwa/hackable/uploads

This grants write permission to owner and group. You should not need to allow world-writable (777), as www-data is the owner.

Accessing DVWA from a Web Browser

All setup is complete. Now point your browser to DVWA’s web interface:

http://127.0.0.1/dvwa/

You may be redirected to setup.php. If not, try going directly to http://127.0.0.1/dvwa/setup.php. This is DVWA’s database setup page.

On the DVWA setup page:

  1. Click “Create/Reset Database”. This will use your new dvwa database and dvwa user to create tables and insert sample data. It should say “Database setup complete!” if successful.
  2. (If it fails, check error messages. Common issues are incorrect DB credentials in config.inc.php or insufficient privileges. The DVWA docs note that any such error likely means credentials mismatch.)

After the database is created, go to the DVWA login page (e.g. http://127.0.0.1/dvwa/login.php) or click the login link. Enter the default credentials:

  • Username: admin
  • Password: password

These defaults are specified in DVWA’s documentation. Upon first login, DVWA will show its home page with a menu of vulnerabilities on the left.

If you see this, congratulations – DVWA is up and running! You can now select different vulnerability modules from the left sidebar.

Troubleshooting Access Issues

  • Blank Page or 500 Error: Check Apache’s error log for PHP errors:

    sudo tail /var/log/apache2/error.log

    If it mentions missing PHP modules (e.g. mysqli), ensure you installed php-mysqli. Also, verify config.inc.php has no syntax errors.

  • Database Connection Error: If you get “Cannot connect to the database”, double-check the database settings in config.inc.php. Ensure the username, password, and hostname exactly match the MariaDB user you created.
  • 403 Forbidden: Ensure file permissions and ownership are correct (chown www-data). Also make sure Apache’s directory settings allow it to serve /var/www/html/dvwa.
  • DVWA Tools Not Working (Ajax issues): The DVWA docs mention some tools (like the advanced API) require special config (e.g. mod_rewrite). If a feature is failing, revisit the PHP config changes (particularly allow_url_include = On) and ensure Apache was restarted.
  • Login Fails: If admin/password doesn’t work, try resetting the database again on the setup page, then login. Also ensure cookies are enabled in your browser.

For more fixes, DVWA’s official docs reference a troubleshooting video covering common setup errors.

DVWA Security Levels

DVWA allows you to switch between security levels that simulate different levels of input validation and hardening. The four levels are:

  • Low: No security at all. Input is used raw. Vulnerabilities are fully exploitable, ideal for beginners to learn basics of an exploit. For example, SQL queries use raw inputs without filtering.
  • Medium: Some basic protections. The developer has attempted rudimentary filtering (e.g. simple string replacement) but it is still bypassable. This level challenges you to find ways around minimal checks.
  • High: Stronger protections. Input is filtered and escaped properly, significantly reducing exploitability. Only advanced techniques succeed at this level.
  • Impossible: Complete security. Most vulnerabilities should not be exploitable in this mode. It’s intended to compare secure code vs vulnerable code.

You can change levels by clicking DVWA Security in the menu after login. This setting applies to all DVWA modules (SQLi, XSS, etc.). Note that in Impossible mode, DVWA intentionally applies strong filtering in each vulnerability code. In High/Medium you see incremental defenses, and in Low essentially none. We will demonstrate exploits at Low (and sometimes Medium) level below.

Detailed Walkthrough of DVWA Modules

DVWA’s left menu lists modules corresponding to common web vulnerabilities. Below is a walkthrough of major modules and how to use them. For brevity, we illustrate a few key ones (you can explore the rest similarly).

SQL Injection

Concept: SQL Injection occurs when user input is directly included in SQL queries, allowing an attacker to modify queries. In DVWA’s SQL Injection module, there is a form field “User ID” which is used in a query like SELECT first_name, last_name FROM users WHERE user_id = '$input'. At low security, this input isn’t filtered.

Figure 1: DVWA SQL Injection (Low security) page showing a query result. At Low security, DVWA simply uses the raw input. For example, entering 1 in the “User ID” field returns the user with ID 1 (in this case, “admin” user). If we submit with a single quote ', we get a SQL error, indicating our input is breaking the query.

The goal often given is: retrieve the passwords of the users. One simple approach is the classic "always-true" trick. For instance, try entering:

1' OR '1'='1

This payload closes the original condition and adds an OR that is always true. Submitting this yields something like:

Figure 2: Using 1' OR '1'='1 returns all users (admin, Gordon, Hack, Pablo, Bob).

Because 1' OR '1'='1 makes the WHERE clause always true, the database returns all rows from the users table. We see multiple “ID:”, “First name:”, “Surname:” lines, one per user. You can then enumerate data (e.g. extract IDs, names, and ultimately crack passwords if hashed).

At Medium or High security, DVWA adds filtering in the source code to block ' OR '1'='1 patterns, requiring more subtle payloads. (For example, URL encoding or bypassing filters.) DVWA’s source for Low mode is essentially "... WHERE user_id = '$id'";, which is why the raw input drives the query.

For completeness, DVWA also has a Blind SQL Injection module (not shown here) where you extract data without direct feedback, using true/false queries.

Cross-Site Scripting (XSS)

Reflected XSS (Low Security): DVWA’s Reflected XSS page has a form “What’s your name?” that echoes your input back. In Low mode, it does not sanitize the input. You can test XSS by entering a script tag. For example:

<script>alert(document.cookie)</script>

When you submit this, the script runs in your browser, popping up an alert with the page’s cookies. In DVWA, this shows a result similar to a logged-in user’s session cookie (note: this is your own browser executing the script).

Figure 3: DVWA Reflected XSS (Low). The alert dialog shows the DVWA PHPSESSID cookie when injecting <script>alert(document.cookie)</script>.

This demonstrates that a malicious link or form could cause a user’s browser to execute arbitrary JavaScript. At higher security levels, DVWA filters or encodes <script> tags to prevent this simple attack, forcing you to encode payloads or find bypasses. (For instance, replacing + with %2B or using alternate syntax.)

Stored XSS: In DVWA’s Stored XSS module, inputs persist in a database (e.g. a guestbook). You can post a JavaScript payload into a form, and when any user (including you) views the page, the script executes. (By default DVWA has a “guestbook” you can sign.) Because DVWA resets the database on each “Create/Reset” in setup, you can reload and try multiple payloads. At Low security, any script you enter will execute for all visitors.

DOM XSS: DVWA also includes a DOM-based XSS challenge. This uses the URL hash or parameters that the page’s own JavaScript interprets unsafely. For example, DVWA’s DOM-XSS page reads a URL fragment like #example and writes it into the page without sanitization. To exploit, you might craft a URL containing a <script> in the fragment. The Reflected and DOM modules demonstrate different XSS techniques; the key idea is that unsanitized data (either server-reflected or client-side DOM) leads to script execution.

Cross-Site Request Forgery (CSRF)

DVWA’s CSRF module has a form (e.g. “Change password”) that, at Low security, lacks an anti-CSRF token. This means an attacker could trick a logged-in user into clicking a malicious link or visiting a page that submits the form on their behalf. To use DVWA’s CSRF lab, log in as admin, then go to CSRF in the menu. There’s a simple form to change the admin password, with fields for “New Password” and “Confirm Password”. In Low mode, you can view the page source and see that there is no hidden CSRF token. You could create another HTML page that submits a POST request to /dvwa/vulnerabilities/csrf/ with new password fields, and the admin’s browser (if logged in) would unknowingly change the password. At higher levels, DVWA will include or check a random token to prevent this.

File Inclusion (LFI/RFI)

The File Inclusion module allows testing for local/remote file inclusion vulnerabilities. DVWA’s form has an input like page= which includes a file on the server. At Low security, it takes your input directly into a PHP include() call. You can try values like ../../../../../etc/passwd to read server files, or even use php://filter/ wrappers. For RFI, you must have allow_url_include=On (which we enabled). In High mode, DVWA may restrict . or disallow remote URLs. This lab teaches how including arbitrary files can leak sensitive data or allow code execution.

Command Injection

The Command Injection page has a form to “ping” a server. It takes your input (a hostname) and appends it to a shell command like ping -c 4 [input]. In Low security, the input is not sanitized, so you can inject shell commands. For example, entering 127.0.0.1; whoami in the host field will cause the server to run ping -c 4 127.0.0.1; whoami. The output will include the result of whoami (usually www-data). In Medium/High, DVWA tries to filter characters like ; or backticks, requiring more creativity (e.g. using & or ( ) encoding).

Brute Force

DVWA’s Brute Force module presents a login form for a user “admin” (or any other you add) with a numeric password. At Low security, it does not lock out after failures. You can use tools like Hydra or Burp Intruder to brute-force the password (which, by default, is a 4-digit pin). For example, configuring Burp Suite to intercept this login request and use the Intruder to iterate password values. This teaches how weak brute-force protections can be bypassed.

File Upload

The File Upload module allows uploading files to the server. At Low security, DVWA may allow uploading any file type (including PHP scripts) and place it in a web-accessible directory. By default, DVWA restricts some file types, but insecure configurations can be tested. E.g., try uploading a simple .php web shell if allowed, then access it via the browser to execute arbitrary code on the host. Always ensure /var/www/html/dvwa/hackable/uploads is writable (we set that above). At higher levels, DVWA may restrict file extensions or check file contents to block malicious uploads.

Insecure CAPTCHA

In Insecure CAPTCHA, DVWA shows a CAPTCHA image (hardcoded or easily guessable) and asks you to type the text. In Low mode, the CAPTCHA value might be stored in a hidden field or global variable. You can bypass it by reading the page source or submitting with the known value. For example, DVWA’s default CAPTCHA code might always be “pass” or visible as plain text in the HTML (Low mode). In High mode, it will generate a random string stored server-side, so you would need to solve the image.

Note: Each DVWA module typically provides hints or instructions in the “Instructions” page link and shows whether the exploit was successful. You should go through each module’s UI to practice and see the effects. DVWA’s code and instructions are meant for learning, so don’t be afraid to click around.

Using Security Tools with DVWA

DVWA is often used as a target for security tools. Here’s how to incorporate popular testing tools:

  • Burp Suite: Configure your browser’s proxy to 127.0.0.1:8080 (Burp’s default). Then browse DVWA pages through Burp’s proxy. You can intercept requests (Proxy → Intercept) to see parameters, then forward them. Use Repeater to modify parameters manually (e.g. inject SQL payloads in the SQLi form and resend). Burp Intruder can automate attacks like brute-forcing or fuzzing (e.g. for the Brute Force or File Upload modules). If you have Burp Professional, its Scanner can actively scan DVWA pages for XSS, SQLi, etc.

  • OWASP ZAP: ZAP is a free alternative to Burp. You can spider and scan DVWA. For example, you can use ZAP’s Automated Scan: right-click on “http://localhost/dvwa” in Sites tree and start an active scan. ZAP will find common issues; the ZAP team notes that a full authenticated scan of DVWA finds many issues including XSS (Reflected, DOM), External Redirect, Path Traversal, Remote OS Command Injection, Remote File Inclusion, SQL Injection, SSRF, etc.. ZAP’s Automation Framework even provides a pre-made plan for scanning DVWA. Remember to set ZAP’s context to include DVWA and handle the login first (you may need to use ZAP’s browser or manually log in through it). ZAP will then crawl and attack DVWA’s endpoints. The ZAP FAQ confirms DVWA version 2.3 works with ZAP 2.15.0, and recommends docker compose up -d for setup in their example.

  • SQLMap: For SQL injection, you can use sqlmap. For instance:

    sqlmap -u "http://127.0.0.1/dvwa/vulnerabilities/sqli/?id=1&Submit=Submit" --cookie="PHPSESSID=<your_session>" --level=5

    This tells sqlmap to target the id parameter. With Low security, sqlmap should detect the injection easily and even dump the database. (You must supply the valid DVWA session cookie for authentication; get it from your browser.)

  • Hydra or Medusa: To attack DVWA’s login (Brute Force), you can use Hydra:

    hydra -l admin -P /usr/share/wordlists/rockyou.txt 127.0.0.1 http-form-post "/dvwa/login.php:username=^USER^&password=^PASS^:F=incorrect"

    This tells Hydra to try passwords from a list for user “admin”, based on the HTML form parameters. Replace the failure string (incorrect) with what DVWA shows on wrong login.

  • Wfuzz / Dirb: You can fuzz for hidden files or directories in DVWA (though it usually only has the listed pages). For example, wfuzz -c -z file,/usr/share/wfuzz/wordlist/directory-list-2.3-medium.txt http://127.0.0.1/dvwa/FUZZ. This can find any forgotten endpoints. (The DVWA file tree can also be explored in /var/www/html/dvwa.)

Using these tools against DVWA helps you practice real pentest workflows in a safe lab. Always point the tools to http://127.0.0.1/dvwa/ and ensure they handle the login session (use Burp or ZAP to intercept your DVWA session).

Troubleshooting Common Setup and Runtime Errors

Even with careful setup, you may encounter issues. Here are common problems and fixes:

  • DVWA Not Starting / Blank Pages: Check that Apache and MariaDB are running. Restart them (sudo systemctl restart apache2 mariadb). Look at /var/log/apache2/error.log for PHP fatal errors. A frequent fix is enabling display_errors=On to see the error on screen.

  • Database Errors: If DVWA says “Unable to establish DB connection” or shows SQL errors, verify config.inc.php credentials. Also ensure the MariaDB user has been granted privileges and FLUSH was run. If you changed the DB user/password after setup, you may need to reset the DVWA DB (setup page → Reset DB) and login again.

  • Permission Denied on Files: Confirm ownership and permissions as in Setting Proper File Permissions above. The official docs note that ./hackable/uploads/ needs to be writeable. If you forgot the chown, run it and reload Apache.

  • Malfunctioning Labs (e.g. API Lab or XSS/DOM): DVWA’s code may have some quirks. For example, one guide suggests editing a curly-brace in medium.php if you get a “variable parse” error. In general, check the DVWA GitHub or community forums for bug fixes. The DVWA README’s Troubleshooting section links a video to “fix DVWA setup issues”.

  • PHP Version Issues: DVWA recommends PHP ≥ 7.3. Newer Kali has PHP 8.x, which works. If you are on an outdated PHP (unlikely with modern Kali), some functions may be deprecated.

  • Cookies and Sessions: If you cannot log in despite correct credentials, ensure cookies are enabled. DVWA sets a PHPSESSID cookie (as seen in [36] and [41]). Also, after running “Create/Reset DB”, DVWA may ask you to log in again.

  • Default Credentials Changed: If someone changed the admin password and you cannot log in, go to the setup page again and reset the database, which restores admin/password (this wipes any data in DVWA).

For ongoing assistance, refer to DVWA’s GitHub issues or community tutorials. The official DVWA documentation acknowledges these problems and directs users to their troubleshooting video.

Docker Setup for DVWA on Kali Linux (Optional)

If you prefer containerization, DVWA provides an easy Docker Compose setup. The DVWA GitHub includes a docker-compose.yml and prebuilt images. This method runs DVWA in containers, avoiding manual package installation. Here’s how to do it on Kali:

  1. Install Docker and Docker Compose:

    sudo apt install -y docker.io docker-compose
sudo systemctl enable --now docker

  2. Clone DVWA for Docker usage:

    git clone https://github.com/digininja/DVWA.git
cd DVWA

  3. Launch the DVWA containers:

    sudo docker compose up -d

    This pulls (or builds) the DVWA image and starts containers. By default, DVWA will listen on port 4280, not the usual 80.

  4. Access DVWA in the browser: Open http://127.0.0.1:4280/ (or http://localhost:4280/). You should see DVWA’s setup page. The Docker environment automatically runs the database setup when you click the button. The default credentials are still admin/password.

  5. Stopping DVWA: When done, you can stop the containers:

    sudo docker compose down

The Docker approach has these advantages:

  • It isolates DVWA in containers (useful for quick reset or cleanup).
  • No need to install Apache/PHP/MariaDB on the host; it’s all in the image.
  • The DVWA container includes PHP 8.x and all dependencies configured.

However, note the port change (4280) and the fact that DVWA files are inside the container. If you want to customize files, you can mount a volume or follow DVWA’s instructions to use your host files in the container (for development, see their docs around pull_policy: build and volumes).

Conclusion

Setting up DVWA on Kali Linux involves installing a web stack (Apache, PHP, MariaDB), cloning the DVWA source, configuring the database and PHP, and adjusting permissions. Once running, DVWA provides a rich platform to practice web vulnerabilities like SQL injection, XSS, CSRF, file inclusion, and more. By systematically following the steps above – updating the system, installing packages, configuring DVWA’s files, and using the setup page – you can have a fully functional DVWA installation.

Always remember to operate DVWA in a safe, isolated environment. Use tools like Burp Suite and OWASP ZAP to scan DVWA just as you would a real web app – the DVWA documentation itself confirms that ZAP’s active scanner finds many vulnerabilities in DVWA. Finally, if you encounter issues, refer to the official troubleshooting guides and ensure your PHP and database settings match the DVWA requirements. With DVWA running on Kali, you now have an excellent hands-on lab for web security learning and testing.

Sources: Official DVWA documentation