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

When learning web-application vulnerability diagnosis, the tool nearly everyone reaches for first is Burp Suite. 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, 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. 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 as "use for the proxy analysis of your own lab." I proceed on the premise of using the localhost-only OWASP 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 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; 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. Without exaggeration, here's an honest list of what can and can't be done.

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, 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 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.

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 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 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.

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/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 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. 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 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.

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.

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). 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, 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 [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, 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 (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.

// 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.

// 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.

# 例：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 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.

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, I explain how this ability is evaluated in the market and leads to projects.

References (official primary sources)

• Burp Suite documentation (PortSwigger official) / Getting Started
• Proxy / Intercept / Burp's browser
• Repeater / Intruder (attack types)
• Scanner / Extensions (Montoya API)
• Web Security Academy (free practice labs) / OWASP Top 10:2025