# The big picture of practical web-app hacking techniques [2026]: a map of attack classes and an assessment methodology — a version faithful to the official docs

> A complete guide to systematically learning web-app attack techniques. It maps the major attack classes — SQLi, XSS, SSRF, JWT, authentication, SSTI — faithfully to the PortSwigger Web Security Academy and OWASP, and organizes them as an assessment methodology of recon → mapping → testing → exploitation → reporting. With legal procedures that complete entirely within your own assets / authorized scope, it explains each attack's 'why it lands' paired with 'how to prevent it by design.'

- Published: 2026-06-28
- Author: 友田 陽大
- Tags: セキュリティ, ホワイトハッカー, 脆弱性診断, Webセキュリティ, 倫理的ハッキング
- URL: https://tomodahinata.com/en/blog/web-application-hacking-techniques-methodology-owasp-portswigger-guide
- Category: 実践Webハッキング技法

## Key points

- Web hacking is methodology, not 'intuition.' With the form recon → mapping → testing → exploitation → reporting, crush attack classes one by one. This article is that map and the entry point to each attack-technique spoke.
- Grasp attack classes in three layers: server-side (SQLi/command injection/SSRF/SSTI/access control), client-side (XSS/CSRF/CORS), and advanced (JWT/deserialization/request smuggling/GraphQL). OWASP Top 10:2025's A01 'broken access control' is still most frequent.
- Tools are subordinate to methodology. With Burp Suite, observe, tamper with, and resend traffic, verifying hypotheses one variable at a time. Automated scanners handle 'vulnerabilities coverable horizontally'; humans handle 'vertical risks judgeable only by design.'
- The absolute condition for legality is 'authorization (scope).' All procedures in this cluster stay within three safe zones (your own assets / CTF / a scope authorized in writing). The instant you point at an unauthorized target, learning becomes a violation of the Unauthorized Access Act.
- Understanding attacks connects directly to defensive design. Each technique always shows 'how it lands' paired with 'how to crush it by design (parameterization, output encoding, signature verification, server-side enforcement of authorization).' Offense and defense are two sides of the same coin.

---

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](https://portswigger.net/web-security) and [OWASP](https://owasp.org/Top10/2025/), 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](/blog/ethical-hacker-law-japan-unauthorized-access-act-active-cyber-defense-disclosure-guide). **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](/blog/ethical-hacking-home-lab-kali-juice-shop-ctf-self-study-roadmap-guide) (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](/blog/burp-suite-getting-started-proxy-repeater-intruder-web-security-testing-guide)'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](https://portswigger.net/web-security/all-topics) 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](/blog/sql-injection-attack-techniques-union-blind-sqlmap-waf-bypass-guide)** — 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](/blog/ssrf-attack-techniques-cloud-metadata-blind-filter-bypass-guide)** — make the server request internal resources (cloud metadata, etc.).
- **[Server-side template injection (SSTI)](/blog/server-side-template-injection-ssti-rce-detection-exploitation-guide)** — 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)](/blog/xss-attack-techniques-reflected-stored-dom-csp-bypass-guide)** — 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](/blog/jwt-attack-techniques-alg-none-key-confusion-secret-cracking-guide)** — signature-verification flaws, alg confusion, key brute force.
- **[Authentication vulnerabilities](/blog/authentication-vulnerabilities-brute-force-2fa-bypass-attack-guide)** — 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](https://owasp.org/Top10/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](/blog/burp-suite-getting-started-proxy-repeater-intruder-web-security-testing-guide), and the iteration of **observe the traffic → form a hypothesis → change just one variable and resend → observe the difference.**

```http
# 方法論の核：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](/blog/web-application-vulnerability-assessment-owasp-zap-sast-dast-guide)) 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](/case-studies/lumber-industry-dx) 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

1. First, put the **map of attack classes and the methodology** into your head with this pillar.
2. Prepare the environment with a [legal lab](/blog/ethical-hacking-home-lab-kali-juice-shop-ctf-self-study-roadmap-guide) and set up [Burp Suite](/blog/burp-suite-getting-started-proxy-repeater-intruder-web-security-testing-guide).
3. Read each spoke ([SQLi](/blog/sql-injection-attack-techniques-union-blind-sqlmap-waf-bypass-guide) / [XSS](/blog/xss-attack-techniques-reflected-stored-dom-csp-bypass-guide) / [SSRF](/blog/ssrf-attack-techniques-cloud-metadata-blind-filter-bypass-guide) / [JWT](/blog/jwt-attack-techniques-alg-none-key-confusion-secret-cracking-guide) / [authentication](/blog/authentication-vulnerabilities-brute-force-2fa-bypass-attack-guide) / [SSTI](/blog/server-side-template-injection-ssti-rce-detection-exploitation-guide)) while getting hands-on in the lab.
4. Once you've built strength, put it into legal real-world practice with [bug bounties](/blog/bug-bounty-getting-started-hackerone-bugcrowd-scope-report-disclosure-guide).

---

## 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](/blog/sql-injection-attack-techniques-union-blind-sqlmap-waf-bypass-guide), 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.

---

### References (official primary sources)

- [PortSwigger Web Security Academy (all topics)](https://portswigger.net/web-security/all-topics)
- [OWASP Top 10:2025](https://owasp.org/Top10/2025/) / [OWASP Web Security Testing Guide (WSTG)](https://owasp.org/www-project-web-security-testing-guide/)
- [OWASP Cheat Sheet Series](https://cheatsheetseries.owasp.org/)