# Burp Suite 入門・実践ガイド【2026】Proxy・Repeater・Intruderで“合法に”Webを診断する — 公式ドキュメント忠実版

> Web診断の世界標準ツール Burp Suite の使い方を、PortSwigger公式ドキュメントに忠実に解説。インターセプトプロキシの仕組み、Burp内蔵ブラウザのセットアップ、Target/Scopeで“許可範囲”を技術的に固定する方法、Repeaterでの手動検証（IDOR例）、Intruderの4攻撃タイプ（Sniper/Battering ram/Pitchfork/Cluster bomb）、Community版とProfessional版の正直な違い、そしてMontoya APIによる自作拡張のJavaコードまで、実リクエスト例とともに。すべて自分の資産・許可スコープ内で完結する合法な手順です。

- 公開日: 2026-06-28
- 著者: 友田 陽大
- タグ: セキュリティ, ホワイトハッカー, Burp Suite, 脆弱性診断, 倫理的ハッキング
- URL: https://tomodahinata.com/blog/burp-suite-getting-started-proxy-repeater-intruder-web-security-testing-guide
- カテゴリ: ホワイトハッカー入門
- 総合ガイド: https://tomodahinata.com/blog/white-hat-hacker-ethical-hacker-how-to-become-certification-roadmap-guide

## 要点

- Burp Suite は、ブラウザとサーバーの間に割り込む『インターセプトプロキシ』。通信を止めて中身を読み・書き換え・再送できるから、画面のUIでは押せない値も自由に検証できる。これがWeb診断の世界標準である理由
- 最初にやるべきは攻撃ではなく Target > Scope の設定。『許可された対象だけ』をスコープに入れ、スコープ外を遮断する——法律で言う“許可”を、ツールの設定として技術的に固定する。柵を先に立ててから手を動かす
- 道具は役割で使い分ける：Proxy（観察）→ Repeater（1リクエストを手で精密検証：IDOR・認可不備に最適）→ Intruder（同じ位置に大量ペイロードを自動投入：4タイプを使い分け）。Scanner（自動診断）はProfessional専用
- Community版は無料で手動ツールが一通り揃うが、Scannerなし・プロジェクト保存なし・Intruderは速度が絞られる（デモ用スロットル）。学習と手動検証はCommunity、本番の反復診断はProfessionalという住み分け
- Burpは公式の Montoya API（Java）で拡張できる。HttpHandler を登録すれば、全レスポンスを横断してセキュリティヘッダ欠落を自動検出する“自分専用チェッカー”を数十行で作れる。診断の知見をコードに畳み込める

---

Webアプリの脆弱性診断を学ぶとき、ほぼ全員が最初に手にするツールが **[Burp Suite](https://portswigger.net/burp)** です。バグバウンティでも、商用のペネトレーションテストでも、事実上の世界標準。本記事は、その Burp Suite を **[PortSwigger公式ドキュメント](https://portswigger.net/burp/documentation)に忠実**に、しかし公式より噛み砕いて、**実際のリクエスト例とコード**つきで解説します。

ただし、最初に一線を引きます。**Burp Suite は強力すぎる道具です。** 向ける先を1つ間違えれば、学習が犯罪に変わります。本記事のすべての操作は、[ホワイトハッカーと法律](/blog/ethical-hacker-law-japan-unauthorized-access-act-active-cyber-defense-disclosure-guide)で定めた**3つの安全地帯（①自分の資産 ②CTF ③書面で許可されたスコープ）**の中で完結します。柵の外には一歩も出ません。

> これは[ホワイトハッカーの独学ロードマップ](/blog/ethical-hacking-home-lab-kali-juice-shop-ctf-self-study-roadmap-guide)で「自分のlabのプロキシ解析に使う」と紹介した Burp Suite を、ツール単体で深掘りするスポークです。練習対象には、同記事で構築した **localhost限定の [OWASP Juice Shop](https://owasp.org/www-project-juice-shop/)** を使う前提で進めます。

---

## 1. Burp Suite とは何か — “インターセプトプロキシ”の正体

Burp Suite の中核は、たった1つの発想です。**あなたのブラウザとWebサーバーの「間」に割り込む。**

```
[ブラウザ] ⇄ 🛡️ Burp Proxy（ここで止めて読む・書き換える）⇄ [Webサーバー]
```

通常、ブラウザが送るHTTPリクエストは一瞬でサーバーに飛んでいきます。Burp はこれを**途中で握り（intercept）**、人間が読める形で停止させます。あなたは中身を**観察し、書き換え、再送**できる。

なぜこれが決定的か。**ブラウザのUIは「正規の操作」しかさせてくれない**からです。`<select>` に無い値、送信ボタンが押せない不正な組み合わせ、隠しフィールドの改ざん、他人のIDへの差し替え——**画面では不可能な入力**を、Burp はプロトコルの層で自由に作れます。脆弱性の多くは、まさにこの「想定外の入力」に潜んでいます。

公式の[Getting Started](https://portswigger.net/burp/documentation/desktop/getting-started)も、この **Proxy → 改ざん → 再送 → 解析** の流れを軸に構成されています。本記事もその順でなぞります。

---

## 2. 【最重要】手を動かす前に — Scopeで“許可”を技術的に固定する

多くの入門記事はここを飛ばしますが、**プロ（と、捕まらないホワイトハッカー）は逆に、ここから始めます。**

法律上、合法/違法を分けるのは技術ではなく **「許可（スコープ）」** です。バグバウンティなら[プログラムが定めたスコープ](/blog/bug-bounty-getting-started-hackerone-bugcrowd-scope-report-disclosure-guide)、業務診断なら契約書のスコープ。**この「許可された対象だけ」を、Burpの設定として固定します。** うっかり対象外（CDN、外部解析、第三者API…）にリクエストを飛ばす事故を、構造的に防ぐためです。

Burp の **Target > Scope** に、対象だけを登録します。

```
# 含める（In scope）— 自分の練習labだけ
http://127.0.0.1:3000/        ← localhostのJuice Shopのみ

# 除外（Exclude from scope）— ログアウトや破壊的操作を誤爆しない
http://127.0.0.1:3000/logout
```

設定したら、必ず **「Proxy intercepts out-of-scope items（スコープ外は握らない）」** 系のフィルタを有効化し、各ツールを **"In scope items only"** に絞ります。これで Burp は**スコープ外の通信を表示・処理しなくなり**、視界がノイズで埋まらず、かつ**範囲外への手出しを技術的に抑止**できます。

> **設計思想として:** 「気をつける」を運用の注意力に頼らず、**設定（コード）で不可能にする。** これは決済の二重課金を“注意”ではなく冪等性で防ぐのと同じ発想です。許可の境界も、人間の集中力ではなく**ツールの制約**で守りましょう。

---

## 3. セットアップ — Community版とProfessional版の“正直な”違い

Burp Suite には[エディション](https://portswigger.net/burp/documentation/desktop/getting-started)があります。誇張なく、**何ができて何ができないか**を正直に並べます。

| 機能 | Community（無料） | Professional（有料） |
|---|---|---|
| **Proxy**（インターセプト） | ✅ | ✅ |
| **Repeater**（手動再送） | ✅ | ✅ |
| **Intruder**（自動投入） | ⚠️ 速度制限あり（デモ用スロットル） | ✅ フル速度 |
| **Target / Site map / Scope** | ✅ | ✅ |
| **Decoder / Comparer / Sequencer** | ✅ | ✅ |
| **Burp内蔵ブラウザ** | ✅ | ✅ |
| **Scanner**（自動脆弱性診断） | ❌ | ✅【Pro専用】 |
| **Burp Collaborator**（OOB検出） | ❌（公式インスタンス利用は制限） | ✅【Pro専用】 |
| **プロジェクトの保存** | ❌ 一時プロジェクトのみ | ✅ ディスク保存 |
| **レポート出力** | ❌ | ✅【Pro専用】 |

**結論:** **学習と手動検証は Community で十分**始められます。Web Security Academy のラボも Community で解けます。一方、**Scannerによる自動診断・大量反復・成果物のレポート化**が要る本番のプロ診断は Professional が前提です。本記事のハンズオンは、**Community で完結**します。

### Burp内蔵ブラウザを使う（プロキシ設定で消耗しない）

昔は「ブラウザのプロキシをBurpに向け、自己署名CA証明書をインストールして…」という面倒があり、初学者の最初の壁でした。**今は不要です。** Burp は **[内蔵ブラウザ（Burp's browser）](https://portswigger.net/burp/documentation/desktop/tools/burps-browser)** を同梱しており、**プロキシもCA証明書も最初から設定済み**。HTTPSサイトも追加設定なしで握れます。

**Proxy > Intercept** タブの **"Open Browser"** を押すだけ。ここで開いたタブの通信が、そのまま Burp を通ります。**まずこれで始めてください。** 外部ブラウザ＋証明書のセットアップは、必要になってからで構いません。

---

## 4. Proxy — 通信を“止めて読む”

セットアップが済んだら、最初のインターセプトです。`make up` で[合法labのJuice Shop](/blog/ethical-hacking-home-lab-kali-juice-shop-ctf-self-study-roadmap-guide)を起動し、内蔵ブラウザで `http://127.0.0.1:3000` を開きます。

**Proxy > Intercept** で **"Intercept is on"** にして、ログイン操作をすると、Burp がリクエストを**握って停止**します。生のHTTPがこう見えます。

```http
POST /rest/user/login HTTP/1.1
Host: 127.0.0.1:3000
Content-Type: application/json
Content-Length: 52

{"email":"test@example.com","password":"password123"}
```

ここでの操作は3つだけ。

- **Forward**：このリクエストを（必要なら書き換えてから）サーバーへ流す
- **Drop**：このリクエストを破棄して送らない
- **Action > Send to ...**：他のツール（Repeater / Intruder）へ送る

公式の[Modifying requests](https://portswigger.net/burp/documentation/desktop/getting-started/modifying-http-requests)が示す通り、**Forwardの前に本文を書き換えれば**、UIでは送れない値をサーバーに届けられます。たとえば上の `email` を `' OR 1=1--` に変えて送る、といった検証はここで行います。

ただし Intercept を**常時オン**にすると、画像やAPIのたびに止まって鬱陶しい。実務では **Intercept は普段オフ**にして全通信を **Proxy > HTTP history** に記録させ、**怪しい1本を見つけたら Repeater / Intruder に送る**、という流れが基本です。

---

## 5. Repeater — 1リクエストを“手で”精密検証する（IDORの実例）

[Repeater](https://portswigger.net/burp/documentation/desktop/tools/repeater/using) は、**1本のリクエストを編集 → 再送 → レスポンス確認、を何度でも繰り返す**ツールです。手動の脆弱性検証の主戦場であり、特に**認可の不備（IDOR）**の確認に最適です。

HTTP history で「自分の注文を見る」リクエストを見つけ、**右クリック > Send to Repeater（`Ctrl+R`）**。Repeater タブでこう編集します。

```http
GET /api/orders/1023 HTTP/1.1          ← 1023 は“自分の”注文ID
Host: 127.0.0.1:3000
Authorization: Bearer eyJhbGciOi...    ← 自分のトークンのまま
```

`1023` を **`1024`（他人の注文ID）**に書き換えて **Send**。ここでレスポンスがこう返ったら——

```http
HTTP/1.1 200 OK
Content-Type: application/json

{"id":1024,"userId":42,"items":[...],"total":12800}
```

**自分のトークンのまま、他人(userId:42)の注文が見えてしまった。** これが典型的な **IDOR（Insecure Direct Object Reference）= アクセス制御の不備**で、[OWASP Top 10:2025](https://owasp.org/Top10/2025/) でも **A01「アクセス制御の不備」**として依然1位の最頻出カテゴリです。

Repeater の強みは、**1リクエストを軸に「条件を1つだけ変えて」挙動の差分を観察**できること。トークンを外したら？ IDを `0` や `-1` にしたら？ メソッドを `DELETE` にしたら？——この**仮説 → 1変数だけ変更 → 再送 → 差分観察**の反復が、診断の核です。

> このIDOR、攻める側の検証はRepeaterで一瞬ですが、**守る側で“設計から”潰す**のは別の難しさがあります。サーバー側の所有者チェックやRLSをどう堅牢化するかは、[Next.js × Supabase のIDOR/認可不備をどう検出するか](/blog/nextjs-supabase-idor-broken-authorization-rls-detection-guide)で解説しています。**攻撃の理解と防御の設計は、同じコインの裏表です。**

---

## 6. Intruder — 同じ位置に“大量のペイロード”を自動投入する

[Intruder](https://portswigger.net/burp/documentation/desktop/tools/intruder) は、**1つのリクエストの「指定位置」に、ペイロード（候補値）を次々入れ替えて自動送信**するツールです。総当たり・ファジング・ユーザー列挙などに使います。

リクエストを **Send to Intruder（`Ctrl+I`）**し、ペイロードを入れたい箇所を **§マーカー**で囲みます。

```http
POST /rest/user/login HTTP/1.1
Host: 127.0.0.1:3000
Content-Type: application/json

{"email":"§admin@juice-sh.op§","password":"§password§"}
```

ここで決定的に重要なのが、公式が定める**4つの攻撃タイプ**です。**§の数とペイロードセットの対応**が、それぞれ全く違います。

| 攻撃タイプ | ペイロードセット | 位置への入り方 | リクエスト数 | 典型用途 |
|---|---|---|---|---|
| **Sniper** | 1セット | 各位置に**1つずつ順番に**（他位置は元値） | 位置数 × ペイロード数 | 1パラメータずつ個別にファジング |
| **Battering ram** | 1セット | **全位置に同じ値**を同時投入 | ペイロード数 | 同じ値を複数箇所に入れる攻撃 |
| **Pitchfork** | 位置ごとに別セット | 各セットを**並行**に1つずつ（zip的） | 最小セットの要素数 | 関連する値の組（user/token対）を順に試す |
| **Cluster bomb** | 位置ごとに別セット | **全組み合わせ**を総当たり | 各セットの**積**（爆発的） | 無関係な値の総当たり（user × pass） |

**選び方の勘所:**

- **1箇所だけ**を試す（例：パスワードリスト攻撃で `password` 位置のみ）→ **Sniper**
- **2箇所に同じ値**（例：同じトークンをヘッダとボディに）→ **Battering ram**
- **対応する組**（例：流出した `user1:passA`, `user2:passB` をそのまま）→ **Pitchfork**
- **総当たり**（例：ユーザー10 × パスワード100 = 1,000通り全部）→ **Cluster bomb**

Cluster bomb は組み合わせ数が **積**になるため、`100 × 100 = 10,000` のように**簡単に爆発**します。ペイロード数を必ず見積もってから走らせてください。

### ⚠️ Community版のIntruderは“わざと遅い”

ここは公式情報として正直に。**Burp Suite Community Edition の Intruder は、デモ目的で速度が制限（スロットル）されています。** リクエスト間に遅延が入り、大量試行を現実的な時間で回すのには向きません（[PortSwigger公式フォーラムでも明言](https://forum.portswigger.net/thread/how-throttled-is-intruder-in-the-community-edition-of-burpsuite-1dea4d42)）。フル速度の自動攻撃は **Professional版**が前提です。

学習目的なら、**少数のペイロードで「攻撃タイプの挙動を理解する」**用途には Community でも十分使えます。総当たりの実戦は Pro、または用途特化のツール（[ZAP](/blog/web-application-vulnerability-assessment-owasp-zap-sast-dast-guide) や `ffuf`、`sqlmap` 等）と使い分けます。

> **倫理の再確認:** Intruder は**認証への総当たり**を容易にします。これを**他人のサイトに向ければ、それは攻撃そのもの**であり、不正アクセス禁止法に直結します。向けてよいのは**自分のlab・CTF・書面で許可されたスコープだけ**。§の数を間違えるより、向ける先を間違える方が、はるかに重大です。

---

## 7. Scanner と周辺ツール — 何が自動化でき、何ができないか

**[Burp Scanner](https://portswigger.net/burp/documentation/scanner)【Professional専用】**は、クロール（サイト探索）と監査（脆弱性検出）を自動化します。XSS・SQLi・各種ヘッダ不備などを機械的に洗い出し、再現手順つきで報告します。**ただしこれは“水平に網羅できる脆弱性”の話**です。

ここに、本ブログが一貫して主張する線引きがあります。

- **自動化できる（水平統制）:** XSS・SQLi・ヘッダ不備・既知パターンの注入——**ツールが網羅検出**できる。Scannerや[ZAP](/blog/web-application-vulnerability-assessment-owasp-zap-sast-dast-guide)、SAST/DASTの土俵。
- **自動化できない（垂直リスク）:** **IDOR・認可ロジックの正しさ・テナント越境・業務ルールの破れ**——ツールは「IDを変えたら200が返った」と気づけても、「それが仕様違反かどうか」は**人間の業務理解**でしか判断できない。

だから Burp は **Scanner（網羅）と Repeater（人間の判断）** の両方を持っています。**Community でも Repeater による垂直リスクの手動検証は完全にできる**——ここが、無料でも学習価値が高い理由です。

その他、覚えておくと良い周辺ツール（多くはCommunityでも利用可）：

- **Inspector** — リクエスト/レスポンスを構造化して読む（ヘッダ・パラメータを整形表示）
- **Decoder / Comparer** — エンコード変換、2レスポンスの差分比較
- **Sequencer** — セッショントークンの**乱数性**を統計分析（予測可能なら重大）
- **DOM Invader** — ブラウザ内蔵で**DOM-based XSS**の発見を補助

---

## 8. 【拡張】Montoya APIで“自分専用チェッカー”を作る（実コード）

Burp の真価は**拡張性**にあります。公式の現行API **[Montoya API](https://portswigger.net/burp/documentation/desktop/extensions/creating-java-extensions)（Java）**を使えば、**全通信を横断する自分専用の検査ロジック**を数十行で書けます（古い `IBurpExtender` 系APIは非推奨・メンテ停止済み。**新規はMontoya一択**です）。

ここでは**「全レスポンスを監視し、セキュリティヘッダの欠落を自動で警告する」拡張**を作ります。診断のたびに目視確認していた項目を、**一度コードに畳み込めば二度と忘れない**——これはまさにDRYです。

### 8.1 エントリポイント

Montoya拡張は `BurpExtension` を実装し、`initialize` でツールを登録します。

```java
// SecurityHeaderExtension.java
package com.example.burp;

import burp.api.montoya.BurpExtension;
import burp.api.montoya.MontoyaApi;

/**
 * 拡張のエントリポイント。Burpが起動時に initialize を1度だけ呼ぶ。
 * ここで「全HTTP通信を見るハンドラ」を登録する。
 */
public class SecurityHeaderExtension implements BurpExtension {
    @Override
    public void initialize(MontoyaApi api) {
        api.extension().setName("Security Header Auditor");
        // HTTPハンドラを登録：以後、Burpを通る全リクエスト/レスポンスがここを通過する
        api.http().registerHttpHandler(new SecurityHeaderHandler(api));
        api.logging().logToOutput("Security Header Auditor: 有効化しました");
    }
}
```

### 8.2 レスポンスを横断検査するハンドラ

`HttpHandler` を実装すると、リクエスト送信前とレスポンス受信後にフックできます。ここでは**レスポンス側**で、重要なセキュリティヘッダの有無を点検します。

```java
// SecurityHeaderHandler.java
package com.example.burp;

import burp.api.montoya.MontoyaApi;
import burp.api.montoya.http.handler.*;
import java.util.List;

/**
 * 全レスポンスを監視し、欠落しているセキュリティヘッダを Output に列挙する。
 * 検査ロジックを1か所に集約（SRP）。判定基準を増やすのはこのクラスだけで済む（ETC）。
 */
class SecurityHeaderHandler implements HttpHandler {
    // 「最低限あるべき」ヘッダ。判定基準の単一の真実源（DRY）。
    private static final List<String> REQUIRED = List.of(
        "Content-Security-Policy",
        "Strict-Transport-Security",
        "X-Content-Type-Options",
        "X-Frame-Options"
    );

    private final MontoyaApi api;

    SecurityHeaderHandler(MontoyaApi api) {
        this.api = api;
    }

    // リクエストは素通し（今回は改ざんしない）
    @Override
    public RequestToBeSentAction handleHttpRequestToBeSent(HttpRequestToBeSent req) {
        return RequestToBeSentAction.continueWith(req);
    }

    // レスポンス受信時に欠落ヘッダを検査
    @Override
    public ResponseReceivedAction handleHttpResponseReceived(HttpResponseReceived res) {
        // hasHeader はヘッダ名を大文字小文字区別なく判定する（公式API）
        List<String> missing = REQUIRED.stream()
            .filter(h -> !res.hasHeader(h))
            .toList();

        if (!missing.isEmpty()) {
            // どのURLで何が欠けているかを Output に出す（後でまとめてレポート化できる）
            api.logging().logToOutput(
                "[欠落] " + res.initiatingRequest().url() + " → " + String.join(", ", missing)
            );
        }
        // レスポンスはそのまま流す（観察に徹し、通信は壊さない＝冪等・非破壊）
        return ResponseReceivedAction.continueWith(res);
    }
}
```

### 8.3 ビルドして読み込む

Kotlin/Java を `.jar` にビルドし、**Extensions タブ > Add** で読み込むだけ。以後、Burpを通る全レスポンスが自動で検査され、ヘッダが欠けたエンドポイントが Output に積み上がります。

```bash
# 例：Gradleでfat-jarを生成し、BurpのExtensionsタブから.jarを追加する
./gradlew jar
# → build/libs/security-header-auditor.jar を Burp の Extensions > Add で読み込む
```

> **応用の発想:** この「全通信を横断し、自分の基準で機械チェックする」型は、そのまま**継続的なセキュリティ統制**に発展します。診断時だけBurpで見るのではなく、**同じ検査をCIに常駐**させれば、ヘッダ欠落は**マージ前に止められる**。手動診断で得た知見を、**コード化 → 自動化 → CIに常駐**と昇華させるのが、本番運用に効く考え方です。PortSwigger は拡張開発のスターターに `CLAUDE.md`（LLM向けの開発コンテキスト）まで同梱しており、**生成AIで拡張を書く**のも現実的な選択肢になっています。

---

## 9. 実務の“型” — 診断1周のレシピ

ツールが揃ったら、毎回考えずに回せる**型**にします。

1. **スコープを固定**（§2）— 対象だけをScopeに入れ、スコープ外を遮断。**ここを飛ばさない。**
2. **マッピング** — 内蔵ブラウザでアプリを一通り操作し、**Proxy > HTTP history / Target > Site map**に全通信を貯める（Interceptはオフ）。
3. **当たりを付ける** — historyから「認可が絡む」「入力をDBに渡す」「リダイレクトする」リクエストを探す。
4. **手動検証（Repeater）** — 怪しい1本を`Ctrl+R`。IDの差し替え・トークン除去・メソッド変更で**差分を観察**。
5. **自動投入（Intruder）** — 列挙・ファジングが要る箇所だけ`Ctrl+I`。攻撃タイプと**件数**を確認してから実行。
6. **（Pro）Scanner** — 水平に網羅すべき注入・ヘッダ系を自動監査。
7. **記録・報告** — 再現手順（リクエスト/レスポンス）を残す。OSSや自作拡張で機械チェックも併走。

この型は、[ZAPを使ったSAST/DAST診断](/blog/web-application-vulnerability-assessment-owasp-zap-sast-dast-guide)とも共通です。**ツールが変わっても、観察→仮説→検証→記録の骨格は同じ**。Burp/ZAPの機能差や使い分けは[スキャナ比較ガイド](/blog/web-application-vulnerability-scanner-tools-comparison-zap-burp-semgrep-guide)を参照してください。

---

## 10. まとめ — 道具の強さは、向ける先の正しさで決まる

- **Burpの正体は割り込みプロキシ**：通信を止めて読み・書き換え・再送する。UIでは作れない入力を、プロトコルの層で自由に作れる。
- **手を動かす前にScope**：許可された対象だけをScopeに固定し、スコープ外を遮断する。**“許可”を設定で固定**してから始める。
- **役割で使い分け**：Proxy（観察）→ Repeater（手動の精密検証＝IDORに最適）→ Intruder（4タイプの自動投入）。Scannerは網羅、Repeaterは判断。
- **Community/Proの正直な線引き**：手動検証と学習はCommunityで完結。自動診断・大量反復・レポートはPro。
- **Montoya APIで自分の基準をコード化**：診断の知見をHttpHandlerに畳み込み、CIまで延ばせば本番統制になる。

Burp Suite は、攻撃者の道具であると同時に、**最も多くを学べる“防御者の顕微鏡”**です。攻撃の手筋を Repeater で体に入れた人ほど、**守る側として「どこが破れるか」を設計段階で見抜けます。** 攻めと守りは同じコインの裏表——次は[ホワイトハッカーの仕事・年収・キャリア](/blog/ethical-hacker-career-path-salary-job-roles-freelance-guide)で、この力が市場でどう評価され、案件につながるかを解説します。

---

### 参考（公式一次情報）

- [Burp Suite documentation（PortSwigger公式）](https://portswigger.net/burp/documentation) ／ [Getting Started](https://portswigger.net/burp/documentation/desktop/getting-started)
- [Proxy / Intercept](https://portswigger.net/burp/documentation/desktop/tools/proxy) ／ [Burp's browser](https://portswigger.net/burp/documentation/desktop/tools/burps-browser)
- [Repeater](https://portswigger.net/burp/documentation/desktop/tools/repeater/using) ／ [Intruder](https://portswigger.net/burp/documentation/desktop/tools/intruder)（[攻撃タイプ](https://portswigger.net/burp/documentation/desktop/tools/intruder/configure-attack/attack-types)）
- [Scanner](https://portswigger.net/burp/documentation/scanner) ／ [拡張（Montoya API）](https://portswigger.net/burp/documentation/desktop/extensions/creating-java-extensions)
- [Web Security Academy（無料の演習ラボ）](https://portswigger.net/web-security) ／ [OWASP Top 10:2025](https://owasp.org/Top10/2025/)