14 · Comparer

Comparer diffs two items side by side — requests, responses, or wordlists — and highlights exactly what changed. It is the fastest way to answer “what did the server actually do differently?”

Proxy → HTTP history → right-click request → Send to Comparer (Ctrl+Shift+B)
Repeater → right-click response → Send to Comparer
Intruder → select two results → right-click → Send to Comparer

Typical Comparer Workflows

15 · Logger

The Logger tab records every request made by every Burp tool — Proxy, Repeater, Intruder, Scanner, and extensions. The Proxy history only shows browser traffic; Logger shows the whole picture, including the automated traffic you generate.

• Live view with filters — filter by tool, host, method, status, and response time
• See exactly what you sent — audit your own Intruder/Scanner runs (and confirm they stayed in scope)
• Debug extensions — watch what an extension requests in real time
• Export/import logs — keep an audit trail for reports and evidence

16 · Extensions

Extensions extend Burp with custom functionality, written against the Montoya API (Java) or the legacy API (Java, Python via Jython, Ruby via JRuby). The BApp Store hosts vetted extensions; you can also load your own or write one in Java.

How to Load an Extension

1. Extensions → BApp Store → search → Install (Professional).
2. Or: Extensions → Extensions → Add → select the extension file (.jar, .py, .rb).
3. Enable it and read the new tab it adds — most extensions register their own UI.
4. Check Output/Errors on the Extensions tab when something misbehaves.

Must-Know Extensions

17 · BApp Store

The BApp Store is PortSwigger’s curated extension marketplace — hundreds of vetted extensions organized by category (Active scanning, Attack, Fuzzing, Proxy, Repeater, Session handling, and more). Extensions install in one click, update automatically, and are reviewed by PortSwigger for safety.

18 · Scanner (Professional)

The Scanner automates vulnerability discovery in two modes: passive (analyzes traffic you already generate — zero extra requests) and active (sends crafted attack traffic to probe insertion points). It is a Professional feature; Community has no Scanner.

How Scanning Works in Practice

1. Browse the app normally — the passive scanner silently checks every request/response (headers, cookies, JS, tech stack, known-bad patterns).
2. Right-click a host or request → Active scan. Burp crawls in-scope content and audits insertion points (URL params, POST bodies, cookies, headers, JSON/XML).
3. Results land in the Dashboard with severity, confidence, and the exact request/response evidence.
4. Right-click any finding → Send to Repeater and verify it manually before reporting.

BChecks — Custom Scan Checks

BChecks are YAML-based definitions that extend the Scanner with your own checks (OOB conditions, custom payloads, bespoke logic). PortSwigger publishes a free BChecks collection on GitHub; you can write and share your own. This is how teams standardize their scan coverage.

19 · Project Options

Project-level settings are stored with the project file (Professional) and define how this test runs. In current Burp versions they live under Settings → Project; older versions had a dedicated Project options tab.

20 · User Options

User-level settings apply to all your projects and live under Settings → User in current versions. These are personal preferences and environment defaults, not test-specific behavior.

21 · Keyboard Shortcuts (Cheat Sheet)

Defaults shown — every shortcut is customizable under Settings → User → Hotkeys.

22 · Common Workflows

These are the six workflows that cover the majority of real web-app testing. Each is a loop: capture → analyze → tamper → observe → document.

Burp Suite vs Other Security Tools

Burp is one tool in a chain. Here is how it fits alongside the rest of the A7 toolset:

How they chain together: Nmap maps the network → Wireshark verifies what actually travels the wire → Burp finds and proves web flaws → Metasploit validates exploitability → your report links evidence from all four. Each tool answers the question the previous one raised.

Hands-On Lab Tutorials (Intentionally Vulnerable Apps)

These labs run against training targets you install yourself — DVWA, WebGoat, OWASP Juice Shop, and the free PortSwigger Web Security Academy labs. No production system is ever touched.

Lab 1 — Proxy: See Every Request Your Browser Makes

1. Start DVWA (Docker: docker run -d -p 80:80 vulnerables/web-dvwa) and configure your browser proxy to Burp.
2. Intercept off → log in to DVWA → open Proxy → HTTP history.
3. Find the login POST and the session cookie; identify the PHPSESSID and its attributes (HttpOnly, Secure, SameSite).
4. Turn Intercept on, submit a form, and tamper a parameter in the Intercept window before forwarding. Watch the response change.

Lab 2 — Repeater: Manual SQL Injection (DVWA, low security)

1. Capture the vulnerable user_id lookup request → Send to Repeater.
2. Submit id=1 — note the normal response; then id=1' — note the SQL error.
3. Try id=1' OR '1'='1' -- - and id=1 UNION SELECT user,password FROM users -- -.
4. Document each request/response pair — this is your evidence chain for SQLi.

Lab 3 — Intruder: Credential Lists and IDOR Enumeration

1. Capture the DVWA login → Send to Intruder → mark the password position.
2. Load a small password list (e.g., 10–20 entries) → Sniper → add grep matches for “Welcome”/”Login failed”.
3. Analyze results: status codes, lengths, and grep hits identify the valid credential.
4. Then capture an object-based request (e.g., id=1) → Numbers payload 1–200 → check for responses exposing data beyond your account.

Lab 4 — Decoder + Sequencer: Tokens Under the Microscope

1. In OWASP Juice Shop, log in and capture the JWT from an authenticated request.
2. Decoder: Base64-decode the header and payload segments — inspect claims like email and role.
3. Try alg: none variants in Repeater (Juice Shop is designed for JWT attacks) — observe the server’s reaction.
4. Capture 100–200 session cookies → Send to Sequencer → analyze randomness and note the effective entropy.

Lab 5 — Full Engagement Workflow on WebGoat

1. Map the app: browse every lesson page → review the site map → add the host to scope.
2. Run passive analysis (Professional) or manual history review (Community).
3. Execute one authorization test (IDOR), one injection test (SQLi/XSS), and one token test (Sequencer).
4. Write a one-page report: scope, tools used, findings with request/response evidence, and remediation per OWASP category.

Case Study (Training Lab Example)

The A7 Web Application Testing Framework

Our seven-gate method for turning a target into a documented assessment — the same discipline we teach in the Web Security Course:

Expert Commentary: A7 Security Hunters’ Perspective

Research & Industry Context (Verified Figures)

The case for web application security testing has never been stronger — and the data is current:

What this means for testers: broken access control (IDORs, privilege escalation) is the single most common class of flaw and it is found only by manual, request-level testing — exactly what Burp’s Proxy/Repeater/Intruder workflow does. Credential abuse, the #1 initial-access vector (22% of breaches, Verizon DBIR 2025), is tested the same way: capture the login, fuzz it, analyze the tokens. Burp Suite is the tool that makes these checks systematic, documented, and reportable.