# Burp Suite getting-started & practical guide [2026]: diagnose the web 'legally' with Proxy, Repeater, and Intruder — faithful to the official docs

> Explains how to use Burp Suite, the world-standard web-diagnosis tool, faithful to the PortSwigger official documentation. From the mechanism of the intercepting proxy, the setup of Burp's built-in browser, how to technically fix the 'permitted range' with Target/Scope, manual verification with Repeater (an IDOR example), Intruder's 4 attack types (Sniper/Battering ram/Pitchfork/Cluster bomb), the honest difference between the Community and Professional editions, to the Java code of a self-made extension via the Montoya API, with real request examples. All are legal procedures that complete within your own assets / permitted scope.

- Published: 2026-06-28
- Author: 友田 陽大
- Tags: セキュリティ, ホワイトハッカー, Burp Suite, 脆弱性診断, 倫理的ハッキング
- URL: https://tomodahinata.com/en/blog/burp-suite-getting-started-proxy-repeater-intruder-web-security-testing-guide
- Category: Intro to ethical hacking
- Pillar guide: https://tomodahinata.com/en/blog/white-hat-hacker-ethical-hacker-how-to-become-certification-roadmap-guide

## Key points

- Burp Suite is an 'intercepting proxy' that cuts in between the browser and the server. Because you can stop the communication and read/rewrite/resend its contents, you can freely verify even values you can't press on the screen UI. This is why it's the world standard of web diagnosis.
- The first thing to do is not attack but the Target > Scope setting. Put 'only the permitted target' in scope and block out-of-scope — technically fix the legal 'permission' as a tool setting. Erect the fence first, then move your hands.
- Use the tools by role: Proxy (observe) → Repeater (precisely verify one request by hand: best for IDOR / broken authorization) → Intruder (auto-inject mass payloads at the same position: use the 4 types). Scanner (auto-diagnosis) is Professional-only.
- The Community edition is free with a full set of manual tools, but no Scanner, no project save, and Intruder is throttled in speed (demo throttle). Community for learning and manual verification, Professional for production repeated diagnosis.
- Burp can be extended with the official Montoya API (Java). Register an HttpHandler and you can make a 'checker just for yourself' that auto-detects missing security headers across all responses in a few dozen lines. You can fold diagnosis know-how into code.

---

When learning web-application vulnerability diagnosis, the tool nearly everyone reaches for first is **[Burp Suite](https://portswigger.net/burp).** In bug bounties and in commercial penetration testing, it's the de facto world standard. This article explains that Burp Suite **faithful to the [PortSwigger official documentation](https://portswigger.net/burp/documentation)**, but more plainly than the official, with **real request examples and code.**

But first, I draw a line. **Burp Suite is too powerful a tool.** Aim it one wrong direction and learning turns into crime. All operations in this article complete within the **3 safe zones (① your own assets ② CTF ③ a scope permitted in writing)** defined in [ethical hackers and the law](/blog/ethical-hacker-law-japan-unauthorized-access-act-active-cyber-defense-disclosure-guide). I don't step one foot outside the fence.

> This is a spoke that deep-dives into Burp Suite as a single tool, introduced in the [self-study roadmap for ethical hacking](/blog/ethical-hacking-home-lab-kali-juice-shop-ctf-self-study-roadmap-guide) as "use for the proxy analysis of your own lab." I proceed on the premise of using the **localhost-only [OWASP Juice Shop](https://owasp.org/www-project-juice-shop/)** built in that article as the practice target.

---

## 1. What is Burp Suite — the true identity of the "intercepting proxy"

Burp Suite's core is a single idea. **Cut in "between" your browser and the web server.**

```
[browser] ⇄ 🛡️ Burp Proxy (stop here to read / rewrite) ⇄ [web server]
```

Normally, the HTTP request the browser sends flies to the server in an instant. Burp **intercepts** this midway and stops it in a human-readable form. You can **observe, rewrite, and resend** the contents.

Why is this decisive. Because **the browser's UI only lets you do "legitimate operations."** A value not in `<select>`, an invalid combination where the submit button can't be pressed, tampering with a hidden field, swapping to someone else's ID — Burp can freely create **input impossible on the screen** at the protocol layer. Many vulnerabilities lurk in exactly this "unexpected input."

The official [Getting Started](https://portswigger.net/burp/documentation/desktop/getting-started) is also structured around this flow of **Proxy → tamper → resend → analyze.** This article traces it in that order too.

---

## 2. [Most important] Before moving your hands — technically fix "permission" with Scope

Many getting-started articles skip this, but **pros (and ethical hackers who don't get arrested) conversely start from here.**

Legally, what divides legal/illegal is not technology but **"permission (scope)."** For a bug bounty, the [scope the program defines](/blog/bug-bounty-getting-started-hackerone-bugcrowd-scope-report-disclosure-guide); for a business diagnosis, the contract's scope. **Fix this "only the permitted target" as a Burp setting.** To structurally prevent the accident of accidentally flying a request out of scope (a CDN, external analytics, a third-party API…).

Register only the target in Burp's **Target > Scope.**

```
# include (In scope) — only my own practice lab
http://127.0.0.1:3000/        ← only the localhost Juice Shop

# exclude (Exclude from scope) — don't misfire logout or destructive operations
http://127.0.0.1:3000/logout
```

Once set, always enable the **"Proxy intercepts out-of-scope items (don't intercept out-of-scope)"**-family filter, and narrow each tool to **"In scope items only."** With this, Burp **stops displaying/processing out-of-scope communication**, your view isn't buried in noise, and you can **technically deter touching outside the range.**

> **As a design philosophy:** don't rely "being careful" on operational attention; **make it impossible by setting (code).** This is the same idea as preventing payment double charges not by "care" but by idempotency. Protect the permission boundary too with **tool constraints**, not human concentration.

---

## 3. Setup — the "honest" difference between the Community and Professional editions

Burp Suite has [editions](https://portswigger.net/burp/documentation/desktop/getting-started). Without exaggeration, here's an honest list of **what can and can't be done.**

| Feature | Community (free) | Professional (paid) |
|---|---|---|
| **Proxy** (intercept) | ✅ | ✅ |
| **Repeater** (manual resend) | ✅ | ✅ |
| **Intruder** (auto-inject) | ⚠️ speed-limited (demo throttle) | ✅ full speed |
| **Target / Site map / Scope** | ✅ | ✅ |
| **Decoder / Comparer / Sequencer** | ✅ | ✅ |
| **Burp's built-in browser** | ✅ | ✅ |
| **Scanner** (auto vulnerability diagnosis) | ❌ | ✅ [Pro-only] |
| **Burp Collaborator** (OOB detection) | ❌ (official-instance use is limited) | ✅ [Pro-only] |
| **Project save** | ❌ temporary project only | ✅ disk save |
| **Report output** | ❌ | ✅ [Pro-only] |

**Conclusion:** **learning and manual verification can fully start with Community.** The Web Security Academy labs can be solved with Community too. On the other hand, production pro diagnosis needing **auto-diagnosis by Scanner, mass repetition, and reporting of deliverables** assumes Professional. This article's hands-on **completes with Community.**

### Use Burp's built-in browser (don't burn out on proxy setup)

In the past there was the hassle of "point the browser's proxy at Burp, install the self-signed CA certificate, and…," which was beginners' first wall. **It's now unnecessary.** Burp bundles **[Burp's browser](https://portswigger.net/burp/documentation/desktop/tools/burps-browser)**, with **the proxy and CA certificate already set from the start.** You can intercept HTTPS sites with no extra setup.

Just press **"Open Browser"** on the **Proxy > Intercept** tab. The communication of the tab opened here passes through Burp as-is. **Start with this.** Setting up an external browser + certificate is fine after you need it.

---

## 4. Proxy — "stop and read" the communication

Once setup is done, the first intercept. Start the [legal lab Juice Shop](/blog/ethical-hacking-home-lab-kali-juice-shop-ctf-self-study-roadmap-guide) with `make up` and open `http://127.0.0.1:3000` in the built-in browser.

Set **"Intercept is on"** in **Proxy > Intercept**, do a login operation, and Burp **intercepts and stops** the request. The raw HTTP looks like this.

```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"}
```

There are only 3 operations here.

- **Forward**: flow this request to the server (after rewriting if needed)
- **Drop**: discard this request and don't send it
- **Action > Send to ...**: send it to another tool (Repeater / Intruder)

As the official [Modifying requests](https://portswigger.net/burp/documentation/desktop/getting-started/modifying-http-requests) shows, **rewrite the body before Forward** and you can deliver a value to the server that the UI can't send. For example, verification like changing the `email` above to `' OR 1=1--` and sending is done here.

But keep Intercept **always on** and it stops on every image and API and gets annoying. In practice, the basic flow is **keep Intercept off** usually, record all communication in **Proxy > HTTP history**, and **when you find one suspicious request, send it to Repeater / Intruder.**

---

## 5. Repeater — "precisely verify" one request "by hand" (an IDOR example)

[Repeater](https://portswigger.net/burp/documentation/desktop/tools/repeater/using) is a tool to **edit one request → resend → check the response, repeating any number of times.** It's the main battlefield of manual vulnerability verification, and especially best for confirming **broken authorization (IDOR).**

In HTTP history, find the "view my order" request, **right-click > Send to Repeater (`Ctrl+R`).** Edit it like this in the Repeater tab.

```http
GET /api/orders/1023 HTTP/1.1          ← 1023 is "your own" order ID
Host: 127.0.0.1:3000
Authorization: Bearer eyJhbGciOi...    ← your own token as-is
```

Rewrite `1023` to **`1024` (someone else's order ID)** and **Send.** If the response comes back like this —

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

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

**With your own token as-is, someone else's (userId:42) order became visible.** This is the typical **IDOR (Insecure Direct Object Reference) = broken access control**, and in [OWASP Top 10:2025](https://owasp.org/Top10/2025/) it's still the #1 most-common category as **A01 "Broken Access Control."**

Repeater's strength is being able to **observe the behavior difference by "changing just one condition" around one request.** What if you remove the token? What if you make the ID `0` or `-1`? What if you change the method to `DELETE`? — this repetition of **hypothesis → change one variable only → resend → observe the difference** is the core of diagnosis.

> This IDOR is verified in an instant on the attacking side with Repeater, but **crushing it "from design" on the defending side** has a different difficulty. How to harden the server-side owner check and RLS is explained in [how to detect IDOR / broken authorization in Next.js × Supabase](/blog/nextjs-supabase-idor-broken-authorization-rls-detection-guide). **Understanding the attack and designing the defense are two sides of the same coin.**

---

## 6. Intruder — "auto-inject mass payloads" at the same position

[Intruder](https://portswigger.net/burp/documentation/desktop/tools/intruder) is a tool that **auto-sends, swapping payloads (candidate values) one after another, into the "specified position" of one request.** It's used for brute-force, fuzzing, user enumeration, etc.

**Send to Intruder (`Ctrl+I`)** with a request and surround the spot you want to put a payload with **§ markers.**

```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§"}
```

What's decisively important here is the **4 attack types** the official defines. **The correspondence of the number of § and the payload sets** is completely different for each.

| Attack type | Payload sets | How it enters positions | Number of requests | Typical use |
|---|---|---|---|---|
| **Sniper** | 1 set | into each position **one at a time in turn** (other positions keep the original value) | positions × payloads | fuzzing one parameter at a time individually |
| **Battering ram** | 1 set | **the same value into all positions** simultaneously | payloads | an attack putting the same value in multiple spots |
| **Pitchfork** | a separate set per position | each set **in parallel** one at a time (zip-like) | the element count of the smallest set | trying related value pairs (user/token pairs) in turn |
| **Cluster bomb** | a separate set per position | brute-force of **all combinations** | the **product** of each set (explosive) | brute-force of unrelated values (user × pass) |

**The crux of choosing:**

- **Just one spot** to try (e.g., only the `password` position in a password-list attack) → **Sniper**
- **The same value in 2 spots** (e.g., the same token in the header and body) → **Battering ram**
- **Corresponding pairs** (e.g., leaked `user1:passA`, `user2:passB` as-is) → **Pitchfork**
- **Brute-force** (e.g., all 1,000 of users 10 × passwords 100) → **Cluster bomb**

Because Cluster bomb's combination count is the **product**, it **easily explodes** like `100 × 100 = 10,000`. Always estimate the payload count before running.

### ⚠️ The Community edition's Intruder is "deliberately slow"

Here, honestly as official info. **Burp Suite Community Edition's Intruder is speed-limited (throttled) for demo purposes.** A delay enters between requests, and it's unsuited for running mass attempts in a realistic time ([also stated explicitly in the PortSwigger official forum](https://forum.portswigger.net/thread/how-throttled-is-intruder-in-the-community-edition-of-burpsuite-1dea4d42)). Full-speed auto-attack assumes the **Professional edition.**

For learning purposes, for "understanding the behavior of the attack types" with a small number of payloads, Community is usable enough. Use the Pro for real brute-force practice, or use-specific tools ([ZAP](/blog/web-application-vulnerability-assessment-owasp-zap-sast-dast-guide), `ffuf`, `sqlmap`, etc.) separately.

> **Re-confirming ethics:** Intruder makes **brute-force against authentication** easy. **Aim this at someone else's site and it's an attack itself**, directly tied to the Unauthorized Access Act. What you may aim it at is **only your own lab, CTF, and a scope permitted in writing.** Getting the direction wrong is far more serious than getting the number of § wrong.

---

## 7. Scanner and peripheral tools — what can and can't be automated

**[Burp Scanner](https://portswigger.net/burp/documentation/scanner) [Professional-only]** automates crawling (site exploration) and auditing (vulnerability detection). It mechanically uncovers XSS, SQLi, various header deficiencies, etc., and reports them with reproduction steps. **But this is a story of "vulnerabilities coverable horizontally."**

Here is the line this blog consistently asserts.

- **Can be automated (horizontal control):** XSS, SQLi, header deficiencies, injection of known patterns — **a tool can detect comprehensively.** The arena of Scanner, [ZAP](/blog/web-application-vulnerability-assessment-owasp-zap-sast-dast-guide), and SAST/DAST.
- **Can't be automated (vertical risk):** **IDOR, the correctness of authorization logic, tenant boundary crossing, and the breaking of business rules** — a tool can notice "I changed the ID and 200 came back," but "whether that's a spec violation" can only be judged by **human business understanding.**

So Burp has both **Scanner (comprehensive) and Repeater (human judgment).** **Manual verification of vertical risk with Repeater is fully possible even on Community** — this is why it has high learning value even for free.

Other peripheral tools worth remembering (many usable on Community too):

- **Inspector** — read the request/response structured (formatted display of headers and parameters)
- **Decoder / Comparer** — encoding conversion, diff comparison of 2 responses
- **Sequencer** — statistically analyze the **randomness** of session tokens (serious if predictable)
- **DOM Invader** — browser-built-in, aids the discovery of **DOM-based XSS**

---

## 8. [Extension] Make a "checker just for yourself" with the Montoya API (real code)

Burp's true value is in **extensibility.** Use the official current API **[Montoya API](https://portswigger.net/burp/documentation/desktop/extensions/creating-java-extensions) (Java)** and you can write **your own inspection logic that crosses all communication** in a few dozen lines (the old `IBurpExtender`-family API is deprecated and maintenance-stopped. **For new work, Montoya is the only choice.**).

Here I make **an extension that "monitors all responses and auto-warns about missing security headers."** Items I'd been visually confirming on every diagnosis — **fold them into code once and you never forget again** — this is exactly DRY.

### 8.1 The entry point

A Montoya extension implements `BurpExtension` and registers the tool in `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 A handler that cross-inspects responses

Implement `HttpHandler` and you can hook before sending a request and after receiving a response. Here, on the **response side**, inspect the presence of important security headers.

```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 Build and load

Build the Kotlin/Java into a `.jar` and just load it with **Extensions tab > Add.** From then on, every response passing through Burp is auto-inspected, and endpoints missing headers pile up in Output.

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

> **The idea of applying it:** this pattern of "crossing all communication and machine-checking by your own criteria" develops directly into **continuous security control.** Rather than looking only at diagnosis time with Burp, **make the same inspection resident in CI** and missing headers **can be stopped before merge.** Sublimating know-how gained from manual diagnosis into **code → automation → resident in CI** is the thinking that works in production operation. PortSwigger even bundles a `CLAUDE.md` (LLM development context) in the extension-development starter, and **writing extensions with generative AI** has become a realistic option too.

---

## 9. The practical "pattern" — a recipe for one round of diagnosis

Once the tools are ready, make it a **pattern** you can run without thinking each time.

1. **Fix the scope** (§2) — put only the target in Scope and block out-of-scope. **Don't skip this.**
2. **Map** — operate the app through the built-in browser and accumulate all communication in **Proxy > HTTP history / Target > Site map** (Intercept off).
3. **Place bets** — from history, find requests that "involve authorization," "pass input to the DB," "redirect."
4. **Manual verification (Repeater)** — `Ctrl+R` one suspicious request. **Observe the difference** with ID swap, token removal, method change.
5. **Auto-inject (Intruder)** — `Ctrl+I` only the spots needing enumeration/fuzzing. Confirm the attack type and the **count** before executing.
6. **(Pro) Scanner** — auto-audit the injection and header types that should be covered horizontally.
7. **Record and report** — leave the reproduction steps (request/response). Also run machine-checks with OSS or a self-made extension in parallel.

This pattern is common with [SAST/DAST diagnosis using ZAP](/blog/web-application-vulnerability-assessment-owasp-zap-sast-dast-guide) too. **Even if the tool changes, the skeleton of observe → hypothesis → verify → record is the same.** For the feature difference and usage of Burp/ZAP, see the [scanner comparison guide](/blog/web-application-vulnerability-scanner-tools-comparison-zap-burp-semgrep-guide).

---

## 10. Conclusion — the strength of a tool is decided by the correctness of where you aim it

- **Burp's true identity is an intercepting proxy**: stop the communication to read/rewrite/resend. You can freely create input the UI can't make, at the protocol layer.
- **Scope before moving your hands**: fix only the permitted target in Scope and block out-of-scope. Start after **fixing "permission" by setting.**
- **Use by role**: Proxy (observe) → Repeater (manual precise verification = best for IDOR) → Intruder (auto-injection of the 4 types). Scanner is comprehensive, Repeater is judgment.
- **The honest line of Community/Pro**: manual verification and learning complete with Community. Auto-diagnosis, mass repetition, and reports are Pro.
- **Code your own criteria with the Montoya API**: fold diagnosis know-how into an HttpHandler, extend it to CI, and it becomes production control.

Burp Suite is both an attacker's tool and **the "defender's microscope" from which you can learn the most.** The more you put the attack's moves into your body with Repeater, the more you can **see through "where it breaks" at the design stage as a defender.** Offense and defense are two sides of the same coin — next, in [an ethical hacker's job, salary, and career](/blog/ethical-hacker-career-path-salary-job-roles-freelance-guide), I explain how this ability is evaluated in the market and leads to projects.

---

### References (official primary sources)

- [Burp Suite documentation (PortSwigger official)](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) ([attack types](https://portswigger.net/burp/documentation/desktop/tools/intruder/configure-attack/attack-types))
- [Scanner](https://portswigger.net/burp/documentation/scanner) / [Extensions (Montoya API)](https://portswigger.net/burp/documentation/desktop/extensions/creating-java-extensions)
- [Web Security Academy (free practice labs)](https://portswigger.net/web-security) / [OWASP Top 10:2025](https://owasp.org/Top10/2025/)