Putting It Together: A Full Web App Pentest Walkthrough

CAP, ACID vs BASE, latency numbers, back-of-envelope estimation, single points of failure — the vocabulary every system designer thinks in.

Core Philosophy: Knowing vulnerabilities individually is not the same as assessing an application. A real penetration test is a methodology — a disciplined, repeatable process that takes you from “here is a target” to “here is a professional report of what’s wrong and how to fix it.” Individual bugs are notes; the methodology is the music. This page assembles everything in Phase 2 into one coherent process.

Part 1: The Problem

Across Phase 2 you learned, one at a time: recon (2.1), your tooling (2.2), the OWASP map (2.3), and the major vulnerability categories (2.4–2.10). But a skilled tester doesn’t think “today I’ll look for SQL injection.” They run a complete methodology that systematically covers everything, in a sensible order, and produces a structured result.

Without methodology, testing is haphazard — you check what you remember, in no particular order, and you can’t tell when you’re “done.” With methodology, testing is thorough, repeatable, explainable, and professional. This page is that methodology, and it’s also a preview of what the job of a penetration tester actually is.

Part 2: The Concept — The Penetration Testing Phases

A penetration test follows a recognized sequence of phases. Different frameworks name them slightly differently, but the shape is consistent:

   1. PRE-ENGAGEMENT   Scope, rules of engagement, authorization,
                          goals — agreed and IN WRITING.
                              │
   2. RECONNAISSANCE   Gather information; map the target.
                              │
   3. SCANNING &       Probe the mapped surface; identify
      ENUMERATION         potential vulnerabilities.
                              │
   4. EXPLOITATION     Confirm vulnerabilities by safely
                          exploiting them; assess real impact.
                              │
   5. POST-            Understand the full consequence of what
      EXPLOITATION        was found (without overstepping).
                              │
   6. REPORTING        Document everything: findings, evidence,
                          impact, remediation — the deliverable.
                              │
   7. REMEDIATION &    The org fixes; the tester often
      RE-TEST             verifies the fixes worked.

Notice the shape: it begins with authorization and ends with a report and re-test. The exciting middle (exploitation) is bracketed by process. Professional security work is process, not just exploits — internalize that now.

Part 3: Phase by Phase — What Actually Happens

1. Pre-engagement — the foundation (page 1.0 made real). Before anything technical: define and write down the scope (what’s in, what’s out), the rules of engagement (allowed techniques, timing, limits), and confirm explicit written authorization. For a bug bounty, this means reading and respecting the program’s scope page. No technical work begins until this is settled. Skipping it isn’t a shortcut — it’s the difference between a pentest and a crime.

2. Reconnaissance — map the target (Phase 2.1). Passive then active recon. Build the attack surface map: subdomains, hosts, technologies and versions, endpoints, content. You’re producing the target map that everything else consults.

3. Scanning & enumeration — find candidate weaknesses. Probe the mapped surface in depth. Port/service scanning, content discovery, fingerprinting, automated scanning. Walk the OWASP Top 10 checklist (2.3) against the app. The output is a list of potential vulnerabilities to investigate.

4. Exploitation — confirm and assess (Phases 2.4–2.10). Take each candidate weakness and confirm it by carefully exploiting it — injection, XSS, broken access control, CSRF/SSRF, misconfiguration, vulnerable components. The goal is confirmation and impact assessment, not destruction or pillage. A confirmed vulnerability with a clear, minimal proof-of-concept is the aim. (Every ethics note from 2.4–2.10 applies here.)

5. Post-exploitation — understand the consequences. For confirmed findings, understand the real business impact. What would this actually let an attacker do? Could findings be chained (see Part 4)? This is what turns a list of bugs into a meaningful risk picture — understood, not necessarily acted upon beyond what’s authorized.

6. Reporting — the actual deliverable (developed fully in 5A.4). The report is the product. See Part 5.

7. Remediation & re-test. The organization fixes the findings; the tester typically re-tests to confirm each fix genuinely works. This closes the loop — and it’s a direct preview of how Phase 2 (attack) hands off to Phase 4 (defend) and back.

Part 4: Chaining — Where Real Skill Shows

A crucial idea that only appears once you work end-to-end rather than bug-by-bug: vulnerability chaining.

Individual vulnerabilities each have some severity. But attackers — and skilled testers — combine several lower-severity issues into one high-severity attack path. The chain is worth far more than the sum of its links.

   Alone, each might be rated "medium":
     • information disclosure leaks a username   (2.9)
     • no rate-limiting on the login             (2.6)
     • an IDOR in the account area               (2.7)

   CHAINED into one attack path:
     leaked username → brute-force the weak login
     → logged in → IDOR to reach every other user's data
   = a "critical" full-account-data compromise.

This is why methodology matters and why post-exploitation thinking matters: you don’t just report three medium bugs, you recognize they form a critical path. Thinking in attack paths rather than isolated bugs is a hallmark of an experienced tester — and it’s the natural payoff of the threat-modeling mindset from 1.2.

Part 5: The Report — Your Actual Product

Say this plainly: in professional security, the report is the deliverable. The client or program doesn’t see you work; they see the report. A brilliant finding, badly communicated, is a wasted finding. Reporting is a core skill — Phase 5A.4 is devoted to it — but here is the shape.

A professional finding contains:

• Title — clear and specific (“Stored XSS in the profile-name field”).
• Severity — a risk rating (likelihood × impact, recall 1.1), often via a standard scoring system.
• Description — what the vulnerability is, in clear language.
• Steps to reproduce — precise, numbered steps so the developer can see it themselves. This is the most important part — an unreproducible finding may as well not exist.
• Evidence — screenshots, request/response captures — proof, gathered responsibly.
• Impact — the real-world business consequence, honestly stated.
• Remediation — concrete, actionable guidance on how to fix it (this is where everything you’ll learn in Phase 4 feeds back in).

And the report overall pairs a high-level executive summary (for non-technical leadership: overall risk posture, key themes) with the detailed technical findings (for the engineers who’ll fix them). Two audiences, one document.

Two qualities define a good report: clarity (anyone can follow it) and actionability (the reader knows exactly what to do next). The tone is professional and constructive — you’re helping the organization improve, not scoring points.

Part 6: The End-to-End Mindset, and the Bridge to Defense

Stepping back — Phase 2 has taken you from knowing nothing about web attacks to being able to run a structured assessment of a web application. The methodology in this page is the thread that ties it all together: authorize → map → probe → confirm → understand → report → re-test.

Two things to carry forward:

First, methodology over tricks. Tools and individual techniques change. The disciplined process — and the mindset behind it — is what makes you reliably effective and genuinely professional. A tester with methodology and modest tools beats a tester with every tool and no method.

Second, this is exactly half of the picture. Everything you found in this phase has a fix. Every report’s “remediation” section is a promise that defense is possible. Phase 4 is where you learn to be the defender — to take each vulnerability class from Phase 2 and design, build, and operate the protection against it. In fact, Phase 4 ends (in 4.9) with the mirror image of this page: a complete defensive walkthrough of an application, ending in a remediation report.

You learned to attack so you can understand. Now the curriculum turns — through Phase 3’s deeper infrastructure attacks — toward learning to defend.

📓 Key Terms

🧪 Hands-On Lab

The capstone of Phase 2. Do this against a deliberately vulnerable web application you run in your own lab, or a sanctioned practice target. This is a full dress rehearsal of the real job.

Task 1 — Pre-engagement. Write your own scope document for the exercise: the target, what you will and won’t test, the “rules.” Even in a lab, practising this step builds the professional habit. State your authorization (you own the lab).

Task 2 — Reconnaissance. Run full recon (2.1) on the target. Produce a complete attack surface map in Notion: hosts, technologies and versions, endpoints, content.

Task 3 — Scanning & enumeration. Probe the mapped surface. Walk your OWASP Top 10 checklist (2.3) against the app systematically. Produce a list of candidate vulnerabilities to investigate.

Task 4 — Exploitation. Work through your candidate list. Confirm each real vulnerability by carefully exploiting it — applying everything from 2.4–2.10. For each, capture minimal, responsible proof. Don’t skip categories because they’re harder; methodology means coverage.

Task 5 — Look for a chain. Review your confirmed findings. Can any be chained (Part 4) into a more serious attack path? Write up at least one potential chain, even a simple one.

Task 6 — Write the report. Produce a real findings report. Include an executive summary and detailed findings, each with title, severity, description, reproduction steps, evidence, impact, and remediation. This is your first portfolio piece (Phase 7.1) — make it genuinely good.

Task 7 — Self-review. Read your report as if you were the developer receiving it. Is every finding reproducible from your steps alone? Is every remediation actionable? Revise until yes. This self-review habit is what makes reports professional.

⚠️ Common Mistakes

• Skipping methodology for “bug hunting by vibes.” Testing what you happen to remember misses categories and can’t tell you when you’re done. Process ensures coverage.
• Skipping pre-engagement. Scope and written authorization are not paperwork to rush past — they are what makes the entire activity legal. This is page 1.0 in operational form.
• Treating the report as an afterthought. The report is the product. A great finding, poorly reported, is wasted. Invest real effort in clarity and reproduction steps.
• Reporting isolated bugs and missing the chain. Experienced testers think in attack paths. Three mediums that chain into a critical is the finding that matters.
• Over-exploiting “to be thorough.” Methodology means confirm and assess, not pillage. Minimal, responsible proof — every ethics note from 2.4–2.10 still applies in the capstone.
• Forgetting the report has two audiences. Leadership needs the executive summary; engineers need reproducible technical detail. Serve both.

✅ Recap & What’s Next

• A penetration test is a methodology, not a pile of tricks: pre-engagement → recon → scanning/enumeration → exploitation → post-exploitation → reporting → re-test.
• Vulnerability chaining — combining lower-severity issues into a high-severity attack path — is where real skill shows, and the findings report is the actual professional deliverable.
• Methodology and process define professional security work, and every attack in this phase has a defense — which is the bridge into the rest of the curriculum.

Phase 2 complete. You can now map a web application, manipulate its traffic, systematically test it against every major vulnerability category, exploit findings responsibly, recognize attack chains, and report it all professionally. That is a genuine, employable, foundational skill set.

Next — Phase 3: Going Deeper — Networks, Infrastructure, and Exploitation. Web apps don’t run in a vacuum; they run on servers, on networks, often inside corporate environments. Phase 3 takes your offensive skills below the web layer — network scanning, service exploitation, privilege escalation, and Active Directory — the infrastructure side of offensive security. Then Phase 4 turns the whole curriculum toward defense.

📋 Phase 2 — Page Checklist

Tick each page when its reading and its hands-on lab are done.

• [ ] 2.1 — Reconnaissance: Information Gathering
• [ ] 2.2 — Burp Suite and the Web Hacker’s Toolkit
• [ ] 2.3 — The OWASP Top 10: The Industry’s Shared Map
• [ ] 2.4 — Injection: SQL Injection and Command Injection
• [ ] 2.5 — Cross-Site Scripting (XSS)
• [ ] 2.6 — Broken Authentication and Session Attacks
• [ ] 2.7 — Broken Access Control and IDOR
• [ ] 2.8 — CSRF, SSRF, and Request Forgery
• [ ] 2.9 — Security Misconfiguration and Exposure
• [ ] 2.10 — Vulnerable Components and the Software Supply Chain
• [ ] 2.11 — Putting It Together: A Full Web App Pentest Walkthrough ← capstone; produces your first portfolio report

Keep growing your living pages:

• [ ] Master Glossary — append every 📓 Key Terms box above.
• [ ] Tools & Reference Cheatsheet — Burp Suite, sqlmap, ffuf/Gobuster, Nikto, Wappalyzer, dependency scanners, and the rest.
• [ ] OWASP Top 10 Testing Checklist — your systematic per-app testing list (from 2.3).

⚖️ Phase 2 standing reminder: every technique here was practised on your own lab, deliberately vulnerable apps, or sanctioned targets — and every exploitation was confirm-and-prove, never pillage. Carry that discipline into Phase 3, where the targets get more powerful.