Burp Suite is the standard toolkit for intercepting, inspecting, and modifying HTTP traffic between a client (browser or mobile app) and a web server. If you can see the request and the response, you can test what matters: authentication, authorization, input handling, session behavior, and the real security posture of the application.

This tutorial focuses on a manual, evidence-driven workflow using Burp Suite Community Edition. After reading it, you should understand what Burp is, how it works, how it helps a pentester, and exactly when to reach for it.

What is Burp Suite?

Burp Suite is an intercepting HTTP(S) / WebSocket proxy plus a set of tools that turn raw traffic into a practical pentesting workflow:

• Capture requests and responses in real time
• Replay requests with controlled edits
• Compare responses to confirm behavior differences
• Automate small, targeted request sets for validation and triage
• Keep clean evidence for report

In short: Burp is where web pentests become repeatable and evidence-driven, not guesswork. It’s also where your manual intuition becomes provable.

Burp ships in three editions: Community (free, manual toolkit), Professional (adds Scanner, Collaborator, project files, full-speed Intruder, Burp AI), and DAST (formerly Enterprise, for CI/CD). This guide covers Community. When a feature is Pro-only, it will be flagged inline, no digging for it later.

When to use Burp Suite

Use Burp when you need to:

• Understand a real request flow (login, checkout, API calls, SPA behavior)
• Validate broken authorization / IDOR / BOLA by changing identifiers and comparing results
• Validate input handling (server-side validation, encoding, parsing differences)
• Test session management (cookies, JWTs, refresh flows, logout)
• Confirm exploitation conditions for common classes (SQLi, XSS, SSRF) without noisy automation
• Produce a clean reproduction for engineering: exact request, exact response, minimal delta

If your question is “what’s the server actually doing here?”, Burp is the right tool.

Benefits for pentesters

• Shows what the client actually sends, not what the UI or the docs claim it sends
• Lets you replay a single request 50 times with tiny variations (Repeater)
• Lets you isolate “is this a bug, or just a UI artifact?” in seconds
• Lets you prove impact with minimal data exposure (response diffing + clean evidence)
• Keeps all your working traffic organized in one project instead of scattered across terminals

How Burp Suite works (mental model)

Burp Suite sits in the middle of the conversation:

Browser / App  →  Burp Proxy  →  Target Server
Browser / App  ←  Burp Proxy  ←  Target Server

For HTTPS, Burp performs TLS interception:

1. Burp generates a local Certificate Authority (CA).
2. You install and trust that CA inside the browser or mobile device you’re testing with.
3. Burp re-signs target certificates on the fly, which is why it can show you plaintext HTTPS.

This is why the setup matters: if your proxy listener or certificate trust is wrong, you’ll either see TLS errors or silently miss traffic. Most “Burp isn’t working” problems are interception-setup problems, not application bugs.

The toolbox

These are the tools you’ll actually use, in order of how often you’ll touch them:

The single most important distinction for beginners: Proxy HTTP history logs traffic that went through the proxy (browser → server). Logger logs traffic generated by Burp’s own tools. When an Intruder attack or an extension misbehaves, Logger is where you debug it.

Setup (current as of April 2026)

Step 1 — Install and launch

Download and install Burp Suite Community from PortSwigger’s download page. Launch it and start a Temporary project — Community only supports temporary projects, which means your work isn’t persisted across restarts. Plan your evidence collection accordingly (export findings to Organizer or to files as you go). Saved project files are a Professional feature and we won’t revisit them here.

On first launch, the Discover tab (introduced in the 2026.1.x line) gives you a curated starting point based on your edition, useful if you want a guided tour before diving into the workflows below.

Step 2 — Use Burp’s built-in browser

Burp ships with a Chromium-based browser, pre-configured to route through the proxy with Burp’s CA already trusted. Use it. It skips two annoying failure modes: manual proxy configuration and manual CA installation. Your personal browser profile stays clean, and TLS interception just works.

You only need an external browser when you genuinely need a specific profile (SSO accounts, password managers, saved sessions), covered in Step 5.

Step 3 — Set your target scope (mandatory)

Scope isn’t optional. Without it you will capture unrelated third-party traffic, your HTTP history becomes unreadable, and you risk touching assets you’re not authorized to test.

1. Go to Target → Scope.
2. Add your target host(s) or URL prefixes. Two useful patterns:
   • Host match (for entire domains and subdomains): e.g. app.example.com with protocol Any
   • URL prefix (for a specific endpoint): e.g. https://app.example.com/api/v2/
3. Enable “Use advanced scope control” if you need regex-level precision.
4. Enable “Drop all out-of-scope requests” in Proxy settings to keep history clean.

See PortSwigger’s scope documentation for the exact UI.

Step 4 — Verify Proxy basics

Open Settings → Tools → Proxy and confirm:

• A proxy listener exists on 127.0.0.1:8080 (default)
• Intercept is OFF by default, you turn it on only when you need it
• Interception rules aren’t set to “intercept everything forever” (that kills productivity fast)

If you ever find your test browser can’t reach the internet after closing Burp, the cause is almost always: Intercept was left on, or the browser is still pointing at a dead proxy listener.

Step 5 — External browser (only when needed)

1. Configure the browser to use 127.0.0.1:8080 as its HTTP/HTTPS proxy.
2. Install Burp’s CA certificate in that browser so HTTPS works without warnings. The CA is exported from Proxy → Proxy settings → Import / export CA certificate.

Done correctly, browsing your in-scope target should populate Proxy → HTTP history immediately.

Step 6 — Keyboard shortcuts worth learning

Two shortcuts will save you hundreds of clicks per engagement:

• Ctrl+R (or Cmd+R on macOS) — send the selected request to Repeater
• Ctrl+I (or Cmd+I) — send the selected request to Intruder

Also useful: Ctrl+F inside Repeater/Inspector for in-request search.

Core workflows

Workflow A — Capture → Triage → Repeat

The loop you’ll run thousands of times:

1. Browse the app normally through Burp’s browser (login, key user journeys).
2. In Proxy → HTTP history, find an interesting request (authenticated action, sensitive data, identifier in the URL or body).
3. Right-click → Send to Repeater (or Ctrl+R).
4. In Repeater, change one thing at a time and resend until you understand the server’s behavior.

One-variable-at-a-time is not a stylistic preference — it’s how you produce proof. If you change three things and the response changes, you don’t know which change caused it.

Workflow B — Authorization testing (IDOR / BOLA) with evidence

Goal: prove that user A can access user B’s data.

1. Authenticate as user A in Burp’s browser and capture a request that references an identifier:
   • GET /api/orders/1001
   • GET /account?userId=1001
2. Send to Repeater.
3. Change only the identifier (1001 → 1002).
4. Compare responses along three axes:
   • Status code changes? (200 → 403 is expected; 200 → 200 with different data is the bug)
   • Response length changes?
   • Sensitive fields present or absent?
5. Use Comparer (right-click response → Send to Comparer, then Compare words/bytes) to generate clean visual proof.

A full worked example is at the end of this section.

Workflow C — Input handling validation

Goal: understand how the server handles data, which is where a lot of vulnerabilities start.

1. Capture a request with user input (search, profile update, API filter).
2. Send to Repeater.
3. Change, one at a time:
   • Encoding (URL-encoded, double-encoded, JSON escaping, Unicode)
   • Content-Type (application/json vs application/x-www-form-urlencoded — sometimes the server accepts both and parses them differently)
   • Edge values (empty, very long, null bytes, unicode normalization edge cases)
4. Watch for server behavior changes:
   • Different validation errors
   • Different code paths triggered
   • Inconsistent normalization (the request hits different parsers)

Use the Inspector panel (right side of Repeater) to decode and edit encoded values inline without leaving the request.

Workflow D — Controlled automation with Intruder

Community’s Intruder is throttled to roughly 1 request per second, so it’s explicitly not a brute-force tool here, it’s an assistive one for small, targeted sets. That constraint is fine for most validation work.

Attack types you need to know:

Typical flow:

1. Send the request to Intruder (Ctrl+I).
2. Clear auto-markers. Mark only the insertion points you care about (§ characters).
3. Pick the attack type. Load your payload list.
4. Start the attack. Sort results by Status, Length, or Response received to find outliers fast.

Important: faster Intruder (via resource pools, parallel connections, and Turbo Intruder-grade throughput) is a Professional feature. Since we’re focusing on Community, we won’t go deeper into Pro tuning, but know that it exists if you hit the throttle limit on real work.

Workflow E — Match and replace (the silent productivity booster)

Found in Proxy settings → Match and replace rules, this lets you rewrite every request or response automatically. Examples that earn their keep daily:

• Inject a X-Forwarded-For: 127.0.0.1 on every request, quick check for IP-based access control bypasses
• Replace User-Agent with a mobile UA to force mobile-only code paths
• Strip cache headers in responses to force the browser to re-fetch assets on every refresh
• Replace a specific JWT/cookie in every outgoing request during a long session test

Turn rules on and off as needed. Forgetting a match-and-replace rule is on and then wondering why the app behaves weirdly is a classic self-inflicted confusion, always check the rules list first when something seems off.

Workflow F — Organizer for clean evidence

Organizer gives you an inbox for requests you want to keep. Right-click any request → Send to Organizer, add a title and notes, and group it into a collection.

This is the single best answer to the “Community has no saved projects” problem: you can export Organizer entries and paste them directly into reports. Pro adds secure sharing of collections via encrypted links; that part we skip.

Worked example — IDOR end-to-end in 5 minutes

Scenario: an e-commerce app at https://shop.example.com exposes an API endpoint that returns order details. You have two test accounts: User A (order IDs 1001, 1002) and User B (order ID 2001).

Step 1. Log in as User A through Burp’s browser. Access your own order:

GET /api/v2/orders/1001 HTTP/2
Host: shop.example.com
Authorization: Bearer eyJhbGciOi...
Cookie: session=a1b2c3...

Response:

HTTP/2 200 OK
Content-Type: application/json
Content-Length: 412
{"order_id":1001,"buyer_email":"userA@example.com","total":199.90,...}

Step 2. Send to Repeater (Ctrl+R). Change 1001 to 2001 (User B’s order). Send.

Step 3. Observe the response.

Safe outcome (authorization is enforced):

HTTP/2 403 Forbidden
Content-Length: 47
{"error":"You do not own this resource"}

Vulnerable outcome (IDOR confirmed):

HTTP/2 200 OK
Content-Length: 418
{"order_id":2001,"buyer_email":"userB@example.com","total":89.50,...}

Step 4. Use Comparer. Right-click both responses → Send to Comparer → Compare words. The diff highlights userA@example.com vs userB@example.com and the differing totals. That’s your evidence.

Step 5. Send the original and modified requests to Organizer. Label the collection idor-orders-endpoint.

Step 6. Write the finding:

• Scope: /api/v2/orders/{id} — GET
• Reproduction: authenticated as User A, requesting User B’s order returns 200 OK with full order payload
• Evidence: request/response pair from Organizer + Comparer diff
• Impact: any authenticated user can enumerate and read arbitrary orders, including PII (buyer email), totals, and line items
• Fix direction: enforce ownership check server-side (order.buyer_id == session.user_id) before returning the resource

That’s a complete pentest finding produced with nothing but Community Edition tooling.

Edge cases worth knowing

WebSockets

Modern SPAs use WebSockets heavily. Burp has a dedicated Proxy → WebSockets history tab , separate from HTTP history. WebSocket messages can also be sent to Repeater for manual replay. If an app “looks static” but reacts to events, check the WebSockets tab before assuming there’s nothing there.

CSRF tokens in Repeater

A common frustration: you replay a request in Repeater, but it fails because the CSRF token expired. The manual workaround in Community is to refresh the relevant page in the browser, grab the new token from Proxy history, and paste it into your Repeater request. Professional solves this with session handling rules that refresh tokens automatically; we don’t cover that here.

Mobile testing (brief)

To route a mobile device through Burp:

1. Put the device on the same network.
2. Set the device’s Wi-Fi HTTP proxy to your laptop’s IP and port 8080.
3. Install Burp’s CA certificate on the device as a system trust anchor (Android: user CAs aren’t trusted by most apps since Android 7).
4. Test. If the app uses certificate pinning, Burp will see TLS handshakes fail, bypassing pinning requires external tooling (Frida, objection) and is out of scope here.

AI + Burp Suite

AI doesn’t replace testing. What it does is reduce thinking overhead, turning raw traffic into hypotheses, and hypotheses into clean write-ups.

What AI is genuinely useful for in the Burp workflow:

• Summarizing a captured flow (login → action → API calls) into a narrative
• Spotting likely authorization boundaries in a request body
• Generating focused variation sets (“what to change to test IDOR vs what to change to test SSRF”)
• Turning evidence (request + response + diff) into a report section with impact and remediation
• Rewriting remediation guidance in developer-friendly language

For a deeper take on how AI is actually integrating into pentester workflows today, read How AI is actually helping pentesters today on the VSec blog.

A concrete prompt template for Community workflows, copy a Repeater request and its response, then ask:

Here is an authenticated HTTP request and response:
[RAW REQUEST]
[RAW RESPONSE]
Task:
1) Identify likely authorization boundaries and trust assumptions.
2) Propose 5 minimal variations to validate IDOR/BOLA.
3) For each variation, define what response delta confirms a bug vs just noise.
4) Draft a report-ready summary: context, repro steps, impact, and fix direction.

That takes you from “interesting request” to “tested hypothesis with report-ready language” in under a minute.

Burp AI note (Pro): Professional includes Burp AI features, explanations for Scanner findings, AI-assisted payload suggestions, and guided exploitation. Since this guide is Community-focused, we won’t go deep on Pro-only AI features. If you want tighter AI integration without paying for Pro, the MCP Server BApp is worth a look, it exposes Burp context to external AI clients via Model Context Protocol. Any data leaving Burp follows the external AI provider’s policies, so review them before connecting production-adjacent traffic.

Common mistakes to avoid

• Leaving Intercept ON all the time. Turn it on only when you need to modify a specific in-flight request, then turn it off. Left on, it will silently block every request the browser makes.
• Skipping scope. Unfiltered history is unreadable and risks out-of-authorization traffic capture.
• Changing multiple variables at once in Repeater. You lose the ability to prove which change caused the behavior.
• Flooding the target with Intruder. Even at 1 req/s, 10,000-entry wordlists are noisy and rarely necessary. Pare the list down.
• Treating TLS errors as application bugs. 95% of “the app is broken in Burp” issues are CA trust or proxy listener misconfiguration.
• Forgetting match-and-replace rules are active. Before declaring “the app behaves weirdly”, check your rules list.
• No evidence trail. If you didn’t save it to Organizer or export it, and Burp restarts, it’s gone, Community has no saved projects.

Pro tips

• Lead every session with scope first, then traffic. Don’t invert this order.
• Use the built-in browser unless you have a hard reason not to. It removes two entire categories of setup errors.
• Ctrl+R everything interesting as you browse, you’ll thank yourself when you realize what you wanted to test 20 minutes in.
• Keep Repeater tabs labeled by intent (right-click tab → Rename). “IDOR test — orders” beats “Tab 17”.
• Use Organizer as you go, not at the end. Memory is expensive; tagging is cheap.
• Install a small set of high-value extensions early: JWT Editor, Autorize, Logger++, Param Miner. All work on Community.

Summary: a safe Burp Suite workflow

1. Start Burp, launch a temporary project, open the built-in browser.
2. Set target scope and enable “drop out-of-scope traffic”.
3. Browse one user journey end to end.
4. Send interesting requests to Repeater (Ctrl+R).
5. Change one variable at a time. Compare responses.
6. Use Intruder only for small, controlled payload sets.
7. Save evidence to Organizer as you go.
8. Use AI to accelerate analysis, variation generation, and write-ups, not to replace validation.

Conclusion

Burp Suite Community becomes genuinely powerful the moment you stop treating it as “a proxy” and start treating it as a manual, evidence-driven testing environment. Scope your work, replay deliberately, change one variable at a time, save evidence as you go, and let AI handle the summarization and write-up overhead. That workflow produces findings that engineering teams can act on, which is, in the end, the only measure of a useful pentest.