Web-app vulnerability assessment is not a world of talent or sense. It's a reproducible "methodology." Excellent assessors don't find vulnerabilities by flashes of inspiration; they hold a map of attack classes and crush them systematically, one by one. This article shows that map and methodology faithfully to the PortSwigger Web Security Academy and OWASP, and is the pillar article that serves as the entry point to the spokes that go deep on each attack technique.
The absolute premise of this cluster (read first) All attack techniques handled here are executed only within three safe zones — ① your own assets ② CTF ③ a scope authorized in writing. This is the line drawn in white hackers and the law. Getting the target wrong by one is far more serious than getting one payload wrong. We proceed assuming a hands-on environment of a legal home lab (OWASP Juice Shop limited to localhost).
1. The assessment methodology — five phases
A pro's assessment runs in the same "form" every time. To reduce thinking and structurally prevent oversights.
| Phase | What to do | Main tools |
|---|---|---|
| ① Recon | Grasp the target's tech stack, subdomains, and public assets | nmap, various OSINT, browser |
| ② Mapping | Enumerate all of the app's endpoints, parameters, and auth boundaries | Burp Suite's Proxy/Site map |
| ③ Testing | Verify each attack-class hypothesis one variable at a time | Burp Repeater / Intruder |
| ④ Exploit | Safely demonstrate the impact of a vulnerability (PoC) | Repeater, dedicated tools |
| ⑤ Report | Record reproduction steps, impact, and fixes | Report, screenshots |
Of these, the one to spend the most time on is ② Mapping. Unless you grasp the attack surface without omissions, no matter how skillfully you test, you won't find the holes. "An entry point you can't see can't be tested" — this is the iron rule of assessment.
2. The map of attack classes — grasp in three layers
The PortSwigger Web Security Academy organizes vulnerabilities into three layers by learning difficulty. This cluster goes deep along this structure too.
2.1 Server-side (the foundation to learn first)
You only need to understand what happens on the server, making it ideal for beginners.
- SQL injection — intervene in the query to read/write the DB. UNION, blind, time-based.
- OS command injection — inject arbitrary commands into the server's shell.
- SSRF — make the server request internal resources (cloud metadata, etc.).
- Server-side template injection (SSTI) — inject template syntax to reach RCE.
- Broken access control (IDOR) — touch others' resources. OWASP A01, most frequent.
- Path traversal / file upload / XXE / NoSQLi
2.2 Client-side
Exploit behavior on the browser side.
- Cross-site scripting (XSS) — reflected, stored, DOM. Execute JS in the victim's browser.
- CSRF / CORS misconfiguration / clickjacking / WebSockets
2.3 Advanced topics
Requiring broader prerequisite knowledge.
- JWT attacks — signature-verification flaws, alg confusion, key brute force.
- Authentication vulnerabilities — enumeration, brute force, 2FA bypass.
- Insecure deserialization / HTTP request smuggling / GraphQL / web cache poisoning / prototype pollution / Web LLM attacks
The compass for what to prioritize searching for is always the OWASP Top 10:2025. In real environments and CTFs alike, A01 "broken access control" and A03 "injection" are overwhelmingly frequent.
3. Tools are subordinate to methodology
The more of a beginner you are, the more your eyes go to "which tool to use," but tools are merely the instruments of methodology. At the center is always an intercepting proxy like Burp Suite, and the iteration of observe the traffic → form a hypothesis → change just one variable and resend → observe the difference.
# 方法論の核：1つの仮説を、1つの変数で検証する（Burp Repeater）
GET /api/orders/1023 HTTP/1.1 # ← 仮説:「IDを変えたら他人の注文が見えるのでは？」
Host: lab.example # 自分のlab/許可スコープのみ
Authorization: Bearer <自分のトークン>
# 1023 → 1024 に変えて再送。レスポンスの差分が、脆弱性の有無を語る。
Automated scanners (Burp Scanner / OWASP ZAP) matter too, but their roles differ.
- Automatable (horizontal control): XSS, SQLi, known-pattern injection, header flaws. Comprehensive detection is the tools' arena.
- Not automatable (vertical risks): IDOR, the correctness of authorization logic, tenant crossing, breaking of business rules. "Whether that's a spec violation" can be judged only by human business understanding.
4. Offense and defense are two sides of the same coin
Each spoke of this cluster always shows "how to prevent it by design" paired right after explaining "how to attack." This isn't mere conscience; it's because the most valuable assessors are those who can design defenses.
| Attack class | Essence of the attack | Defense by design |
|---|---|---|
| SQLi | Input mixed into the query structure | Parameterized queries (placeholders) |
| XSS | Ignoring context at output time | Context-specific output encoding + CSP |
| SSRF | Leaving the URL's destination to input | Allowlist + metadata blocking (IMDSv2) |
| JWT | Cutting corners on signature verification | Fixed algorithm + strict signature verification |
| Authentication | Guessable, enumerable | Rate limiting + constant error responses + MFA |
| SSTI | Concatenating input into a template | Don't make user input a template |
The more one understands attacks, the more they can proactively point out "this breaks here" in a design review. I myself, while building an METI-Minister's-Award-winning B2B SaaS and a payments platform with 0 double charges in production with one-person × generative AI, have keenly felt that "the power to build fast" and "the power to build safely" are two sides of the same coin.
5. How to walk this cluster
- First, put the map of attack classes and the methodology into your head with this pillar.
- Prepare the environment with a legal lab and set up Burp Suite.
- Read each spoke (SQLi / XSS / SSRF / JWT / authentication / SSTI) while getting hands-on in the lab.
- Once you've built strength, put it into legal real-world practice with bug bounties.
6. Summary
- Hacking is methodology: recon → mapping → testing → exploitation → reporting. Spend the most time on mapping.
- Hold attack classes as a map: server-side → client-side → advanced. OWASP A01/A03 are most frequent.
- Tools are instruments of methodology: verify one variable at a time with Burp. Scanners cover; humans judge.
- Offense and defense are two sides: always understand each attack paired with defense by design.
- The absolute condition for legality is authorization: keep all procedures within the three safe zones.
Next, let's get hands-on starting with the complete conquest of SQL injection, the most frequent and most impactful.
For those who think "I'm anxious about whether our app can withstand these attacks." I take on actually reproducing and diagnosing the attack classes handled here on your app, and fixing them from the design. I can also visualize the current state with free OSS first. Feel free to reach out via the links at the end of the article.