I conducted a black-box web application penetration test against Acunetix's public, intentionally-vulnerable test target following the OWASP Testing Guide v4.2 and PTES methodology. The assessment produced seven documented findings spanning Critical to Low severity, each with evidence, CVSS scoring, impact analysis, and prioritized remediation guidance. Because the target is a legally-sanctioned public test site with no real victim, this is the one case study I can publish with full payloads rather than sanitized placeholders.
- Two Critical findings — SQL Injection (CVSS 9.8) and Cross-Site Scripting (CVSS 9.3) — together allow full application compromise and unauthenticated attacks against visitors
- Root cause was consistent across nearly every finding: insufficient input validation, no parameterized queries, unencrypted transport, and missing security headers
- All seven findings map directly to the OWASP Top 10, demonstrating that classical, well-documented vulnerability classes remain fully exploitable when basic controls are absent
- Remediation priority was sequenced by exploitability and impact, not just CVSS score alone — SQLi and XSS given a 24-hour fix window
The Problem
The engagement scope was a black-box assessment of a live web application with no prior knowledge of its internals — reconnaissance, scanning, exploitation, and reporting all conducted from an external attacker's vantage point. The goal was to determine the application's actual security posture against real exploitation techniques, not just run an automated scanner and report raw output.
The Approach
I followed the five-phase OWASP/PTES methodology:
- Reconnaissance — passive and active information gathering: DNS records, WHOIS, HTTP header analysis, directory enumeration
- Scanning & enumeration — port scanning with Nmap, web vulnerability scanning with Nikto and OWASP ZAP, technology fingerprinting
- Exploitation — manual and automated exploitation using Burp Suite Community and SQLMap, validating every scanner-flagged issue by hand rather than trusting automated output alone
- Post-exploitation — assessing real-world impact: what data could actually be accessed, what privilege escalation was possible
- Reporting — full documentation with evidence, CVSS scoring, and remediation guidance for each finding
Every automated scanner finding was manually re-validated before being included in the report. Automated tools produce false positives; a professional VAPT report only documents what's been confirmed exploitable.
Technical Analysis — Findings Summary
SQLMap session against the target — connection retries logged during testing, consistent with the manual re-validation approach described below
| # | Finding | Severity | CVSS |
|---|---|---|---|
| 01 | SQL Injection — login form & search parameter | Critical | 9.8 |
| 02 | Cross-Site Scripting (Reflected & Stored) | Critical | 9.3 |
| 03 | Local File Inclusion | High | 8.6 |
| 04 | Broken Authentication — weak creds, no lockout | High | 7.5 |
| 05 | Sensitive Data Exposure — unencrypted HTTP | High | 7.4 |
| 06 | Directory Listing Enabled | Medium | 5.3 |
| 07 | Missing Security HTTP Headers | Low | 3.1 |
Challenges
Separating signal from scanner noise. Automated scanning surfaced dozens of low-confidence findings. Prioritizing manual exploitation time against the handful likely to be real — and confirming each one with a working proof-of-concept — was the actual skill exercised here, not running the tools themselves.
Communicating impact, not just technical detail. A CVSS score alone doesn't tell a stakeholder what SQL Injection actually means for their business. Every finding write-up pairs the technical mechanism with a plain-language impact statement — full database extraction, session hijacking, unauthenticated visitor attacks — so remediation priority is self-evident.
Results
- Seven findings documented end-to-end — evidence, CVSS, impact, and remediation — against the OWASP Testing Guide v4.2 + PTES standard
- Every scanner-flagged issue manually validated before inclusion, keeping the false-positive rate at zero in the final report
- Delivered a remediation priority matrix sequencing fixes by exploitability and business impact, not raw severity score alone
- Overall application posture assessed as Critical, with a clear 24-hour / 3-day / 1-week / 1-month remediation timeline
Lessons Learned
The consistency of root cause across all seven findings — missing input validation and no parameterized queries — reinforced that most real-world web application compromise doesn't require novel technique. It requires patient, methodical testing against known vulnerability classes that defenders assume are "solved" but frequently aren't implemented correctly in practice.
What I'd Improve
- Add automated regression testing hooks so remediated findings can be re-verified without a full manual re-test cycle
- Extend the assessment to include authenticated-user testing paths, which often surface a different vulnerability class than black-box unauthenticated testing alone
- Build a standard report template with a one-page executive summary suitable for non-technical stakeholders, separate from the full technical findings
References
- OWASP Testing Guide v4.2 — owasp.org
- PTES — Penetration Testing Execution Standard
- Full repository — github.com/Cyber-Nate/VAPT-testphp-vulnweb-com