Disclaimer: This article is provided strictly for educational purposes and authorized security testing. Only run these techniques against systems you own or have explicit written permission to assess. Unauthorized access to computer systems is illegal in virtually every jurisdiction and can carry severe penalties.
Introduction
Burp Suite is the industry-standard intercepting proxy and web application testing platform. At its core is a man-in-the-middle HTTP(S) proxy that sits between the browser and the target application, letting a tester see, pause, and modify every request and response as it happens. Around that proxy, Burp provides a set of tightly integrated tools — Target/Site map, Repeater, Intruder, the active/passive Scanner (Burp Suite Professional), and an extension ecosystem (BApp Store) — that turn raw traffic capture into a structured testing methodology.
What separates a productive Burp workflow from ad-hoc clicking is discipline in how traffic is scoped, tagged, and escalated: not every request needs manual review, but every request touching authentication, authorization, or user-controlled input deserves it. A well-run session builds a reproducible chain from passive observation (Proxy/Target) to manual manipulation (Repeater) to automated variation (Intruder) to broader coverage (active scanning), with match/replace rules and session-handling macros doing the repetitive work between them.
Attack Prerequisites
A functional Burp testing session depends on the following being in place:
- Proxy positioned correctly — browser (or mobile device/thick client) configured to route traffic through Burp’s listener (default
127.0.0.1:8080), and Burp’s CA certificate installed/trusted by the client so TLS interception does not break the connection. - Defined scope — target host(s) added under Target > Scope so Proxy history, Scanner, and Logger noise is filtered to in-scope traffic only, and so out-of-scope third-party requests are excluded from active testing.
- Valid session/authentication — a logged-in session (cookie, bearer token, or API key) captured in the Proxy history to seed Repeater and Intruder requests; many findings require testing both authenticated and unauthenticated request paths.
- Authorization to actively test — Intruder brute-forcing and the active Scanner send a high volume of modified/malicious requests and must only be run against systems covered by written testing authorization.
How It Works
Burp’s proxy intercepts by terminating the client’s TLS connection itself (presenting a certificate signed by Burp’s own CA, which is why that CA must be trusted by the client) and opening a second TLS connection to the real server, giving it a clear-text view of both directions of traffic. Every request/response pair is logged to the Proxy history and, if in scope, populates the Target > Site map with discovered endpoints, parameters, and response codes — effectively building the attack surface from normal browsing.
Repeater takes a single captured request and lets the tester resend it with arbitrary edits, observing the response each time — this is where manual hypothesis testing happens: does changing a parameter type reveal a stack trace, does an IDOR-suspect ID return another user’s data. Intruder automates the same idea across many payload values in one or more positions of a base request, using one of four attack types (Sniper, Battering ram, Pitchfork, Cluster bomb) to control how payload sets combine across positions — Sniper cycles one payload set through each position in turn, Cluster bomb tries every combination across multiple positions, which is how parameter-pair fuzzing and credential spraying are typically built.
Session handling is where Burp workflows break down if ignored: modern apps issue short-lived tokens, CSRF tokens, or re-authenticate mid-flow, so a naively replayed Intruder/Repeater request goes stale. Burp addresses this with session handling rules built from macros — a macro is a recorded sequence of requests (e.g. log in, then extract a fresh CSRF token) that Burp replays automatically before or during another tool’s requests, substituting the freshly captured token/cookie so long automated runs (Intruder, Scanner) don’t die on the first expired session.
Practical Example / Configuration
A Proxy match and replace rule is the simplest way to make a durable change across all traffic — for example forcing a weakened Accept-Encoding so responses stay readable in plaintext, or stripping a security header for testing its absence. Configured under Proxy > HTTP history > right-click > ‘Do intercept’ settings, or Settings > Tools > Proxy > Match and replace:
# Match and replace rule (Settings > Proxy > Match and replace)
Type: Request header
Match: Accept-Encoding: .*
Replace: Accept-Encoding: identity
Comment: Disable gzip/br so proxy history stays human-readable
Type: Response header
Match: Content-Security-Policy: .*
Replace: (leave blank -- deletes the header)
Comment: Remove CSP in the browser render for DOM XSS PoC confirmation
A session-handling macro keeps Intruder/Scanner authenticated across a long run. This example logs in, harvests a CSRF token from the response body, and applies it to every subsequent request in the rule’s scope:
# Project options > Sessions > Macros > Add
# Recorded macro (2 requests):
# 1. GET /login -> capture csrftoken from response body
# 2. POST /login -> body includes {csrftoken} + credentials
# Session Handling Rule (Project options > Sessions > Session Handling Rules)
Rule name: Maintain authenticated session
Scope: Tools = Intruder, Scanner, Repeater; URL = target scope
Actions:
1. Check session valid -- cookie 'session' present, response lacks
"Please log in"
2. If invalid: run macro "Login and fetch CSRF"
3. Update param csrftoken via regex: name="csrf_token" value="([a-f0-9]{32})"
An Intruder cluster-bomb configuration for testing an IDOR across two independent parameters — object ID and a tenant/org identifier — with a numeric range payload set on each position:
# Intruder > Positions (attack type: Cluster bomb)
GET /api/v2/org/{ORGID}/invoice/{INVID} HTTP/1.1
Host: app.example.com
Cookie: session=<captured-authenticated-session>
# Intruder > Payloads
Payload set 1 (ORGID): Payload type = Numbers, Range 1000-1050, Step 1
Payload set 2 (INVID): Payload type = Numbers, Range 8000-8100, Step 1
# Intruder > Settings > Grep - Match
Flag responses containing: "invoice_total" (successful cross-tenant read)
# Sort results by Length / Status code to spot the outliers programmatically
Walkthrough / Exploitation
A representative authenticated web-app assessment flow, tool by tool:
# Step 1 -- crawl/browse the app normally through the proxy to populate
# Target > Site map; confirm scope is set to the target host(s) only.
# (No CLI here -- this is browser traffic through 127.0.0.1:8080.)
# Step 2 -- send an interesting request from Proxy history to Repeater
# (right-click > 'Send to Repeater', or Ctrl+R) and manually probe it:
GET /api/v2/user/1042/profile HTTP/1.1
Host: app.example.com
Cookie: session=abc123...
# Change 1042 -> 1041 and resend; compare response body/status
# to confirm or rule out an IDOR before automating it in Intruder.
# Step 3 -- promote the confirmed-interesting request to Intruder,
# mark the object-ID position with section markers, choose payload set,
# and run the attack (Cluster bomb / Sniper as appropriate).
GET /api/v2/user/\xa7 1042 \xa7/profile HTTP/1.1
# Step 4 -- right-click the in-scope site map node > 'Scan' (Burp Pro),
# using the session-handling macro so the scanner stays logged in.
Each stage hands a narrower, better-understood target to the next tool: Proxy/Target for coverage, Repeater for hypothesis testing on a single request, Intruder for systematic variation once a hypothesis is worth automating, and the active Scanner for breadth once session handling makes unattended crawling reliable.
Note: Burp Community Edition has no active Scanner and a throttled Intruder; the workflow above assumes Professional for the Scanner step, but Proxy, Repeater, Intruder, and session-handling macros work identically in Community.
Opsec: Match/replace rules and macros are easy to leave enabled after a test and silently corrupt later traffic — disable or scope rules tightly, and always verify Target scope before running Intruder or an active scan so out-of-scope third-party hosts (CDNs, analytics, SSO) are never sent attack traffic.
Detection and Defense
Burp’s traffic is distinguishable from normal browser traffic in several ways, and defenders testing their own applications should watch for the same signals an attacker’s Burp session would generate:
- Rate and pattern anomalies — Intruder and active Scanner generate many requests per second against the same endpoint with only small payload differences, visible in WAF/CDN logs as a spike from a single source IP/UA.
- User-Agent and header fingerprints — unmodified Burp traffic often carries a default/missing User-Agent, and Collaborator/Scanner probes leave characteristic values (long random tokens, out-of-band callback domains) in access logs.
- WAF/rate-limiting on authentication and object-ID/password-reset endpoints to blunt Intruder-driven IDOR and brute-force sweeps regardless of tooling.
- Server-side authorization checks independent of client-supplied IDs — the durable fix for the IDOR class Intruder is used to find is enforcing object-level authorization on every request, not sequential-ID obscurity.
Because Burp is also the tool defenders use to validate fixes, the same Repeater/Intruder workflow doubles as regression testing: replaying a previously vulnerable request after a patch confirms the fix holds.
Real-World Impact
Burp Suite is referenced throughout OWASP’s Web Security Testing Guide and is the de facto tool in most professional web application penetration tests and bug-bounty workflows; its Collaborator feature is widely used to confirm out-of-band vulnerability classes (blind SSRF, blind XXE) that produce no direct response evidence. IDOR/broken object-level authorization — the bug class the Intruder example above targets — has been the top entry in the OWASP API Security Top 10 (API1) and is routinely found via exactly this Repeater-then-Intruder workflow.
Conclusion
Burp’s power comes from the pipeline, not any single feature: passive coverage through Proxy/Target, manual confirmation in Repeater, systematic automation in Intruder, and session-handling macros that keep all of it authenticated over long runs. A tester who understands what each tool sends and why — rather than clicking ‘Scan’ on a whole site with no scope — produces faster, more accurate, and far less noisy results.
You Might Also Like
If you found this useful, these related deep-dives cover adjacent techniques and their defenses:
Comments