What Penetration Testing Actually Is (and Requires)
Penetration Testing Methodology
Chapter 1 · What Penetration Testing Actually Is (and Requires)
This site already has deep, dedicated courses on specific vulnerability classes — xss1, csrf1, sqli1, bc1, dbsec1, and the owasp1 survey course tying several of them together. This course is different: it's not about any one vulnerability. It's about the process a professional actually follows to find and prove real security weaknesses in a target system — and before a single technique gets named, there's one precondition that has to be true first.
Penetration Testing vs. Related Disciplines
"Security testing" covers several genuinely different activities, often confused with each other:
| Discipline | What it actually does | Typical scope/duration |
|---|---|---|
| Vulnerability Scanning | Automated, tool-driven identification of known vulnerability signatures — largely non-invasive, doesn't attempt exploitation | Continuous or scheduled, broad |
| Penetration Testing | Manual, expert-driven testing that attempts real exploitation to prove actual, demonstrable impact — this course's own subject | Time-boxed, formally scoped engagement |
| Red Teaming | A broader, more adversarial simulation of a real determined attacker's full campaign — often combining technical, physical, and social engineering vectors, and often unannounced to the target's own defenders, specifically to test detection and response | Longer, goal-oriented rather than checklist-oriented |
| Bug Bounty Hunting | Crowdsourced, ongoing testing against a publicly published scope/policy — anyone meeting that policy's terms can participate and get paid for valid findings | Open-ended, no single formal engagement window |
This course focuses specifically on penetration testing — but the precondition covered next applies, in one form or another, to every discipline in that table.
The Single Non-Negotiable Precondition — Written Authorization
Before any reconnaissance, any scanning, any attempt at exploitation — before anything this course covers from Chapter 4 onward — one thing has to already be true: explicit, written authorization from someone with actual legal authority over the target system. Not a verbal "sure, go ahead." Not an assumption that testing is welcome because a company has a bug bounty page somewhere. A real, specific, written agreement, in place before testing starts.
What Authorization Actually Looks Like
In practice, authorization takes the form of a written scope agreement or Rules of Engagement (RoE) document — sometimes informally called a "get out of jail free" letter — signed by someone who genuinely has the authority to grant it for the specific systems being tested. It defines, in writing, exactly what's in scope, what testing windows are permitted, what techniques are and aren't allowed, and who to contact if something unexpected happens during testing. pentest1-2 covers the full structure of this document in depth.
Bug bounty programs work slightly differently: authorization comes from the program's own published policy rather than an individually signed document — but the same underlying principle holds. Testing anything outside that policy's own stated scope is exactly as unauthorized as testing a company with no bug bounty program at all.
What This Course Covers
| Chapter | Topic |
|---|---|
| 2 | Engagement Types & Scoping |
| 3 | Standard Methodology Frameworks |
| 4 | Reconnaissance & OSINT |
| 5 | Scanning & Enumeration |
| 6 | Vulnerability Analysis — The Toolkit This Site Already Built |
| 7 | Exploitation — Proving Impact Without Causing Harm |
| 8 | Post-Exploitation & Privilege Escalation |
| 9 | Reporting — The Actual Deliverable |
| 10 | Capstone: Scoping and Planning a Real Engagement |
Hands-On Exercises
Using this chapter's own comparison table, explain the specific difference between vulnerability scanning and penetration testing — what does a pentest do that a scan deliberately does not?
📄 View solutionA well-meaning developer notices what looks like an exposed admin panel on a company's public website and decides to "test" whether it's actually vulnerable, intending to report it responsibly if so. Using this chapter's own warn-box, explain what's legally wrong with this plan, regardless of the developer's intentions.
📄 View solutionExplain how authorization works differently for a formally scoped penetration test versus a bug bounty program, and explain why testing something outside a bug bounty program's own published scope is still unauthorized, even though the company clearly welcomes security research in general.
📄 View solutionChapter 1 Quick Reference
- Vulnerability scanning — automated, non-invasive · Penetration testing — manual, attempts real exploitation · Red teaming — broader adversary simulation, often tests detection/response · Bug bounty — crowdsourced, ongoing, scoped by published policy
- Written authorization from someone with real legal authority over the target is the single non-negotiable precondition — before any technique in this course is used
- Unauthorized access is a real crime (the CFAA in the US, comparable laws elsewhere) — good intentions provide no legal protection
- Authorization takes the form of a scope agreement / Rules of Engagement (RoE) document, signed before testing begins — full structure covered in pentest1-2
- Bug bounty authorization comes from a program's own published policy — testing outside that scope is exactly as unauthorized as testing a company with no program at all
- Every later chapter in this course assumes authorization already exists — it's the foundation, not a footnote
- Next chapter: Engagement Types & Scoping — Black Box/White Box/Gray Box, and why scope must be precisely defined in writing