Burp Suite for Web Application Security Testing: A Practitioner's Guide

Burp Suite is the de facto standard for manual web application security testing. Ask any professional pentester what tool they spend the most time in, and the answer is almost always Burp. It sits between your browser and the target application, giving you complete visibility and control over every HTTP request and response. If you are doing web security work without understanding Burp, you are missing most of the picture.

This guide covers how professional pentesters actually use Burp Suite — not the marketing overview, but the workflows, configurations, and techniques that matter in real engagements. We will cover proxy setup, the core tools, active scanning with Burp Pro, Intruder attack strategies, the extensions that make Burp genuinely powerful, and where the tool's limits are.

Community vs Pro: What Actually Differs

Burp Suite Community is free and sufficient for learning and basic manual testing. Burp Suite Professional costs around $499/year per user and is what everyone uses in production engagements. The gap is larger than it looks on the feature list.

Community limitations that actually hurt you:

• No Burp Scanner — you can proxy and intercept, but there is no automated vulnerability detection
• Intruder is rate-throttled to roughly one request per second, making it nearly useless for fuzzing
• No project files — everything is lost when you close the tool
• No Burp Collaborator — out-of-band detection (for blind SSRF, XXE, blind SQLi) requires Pro or an external OAST server
• No Bambda filters (the modern request filtering system) in older Community builds

For anything beyond basic proxy interception and Repeater use, you need Pro. Enterprise edition adds a web UI, scheduled scanning, and CI/CD integration at a significantly higher price point.

Proxy Setup and CA Certificate Installation

Burp's proxy listens on 127.0.0.1:8080 by default. Point your browser at it and Burp intercepts all HTTP traffic. The setup friction comes from HTTPS — you need to install Burp's CA certificate so your browser trusts the intercepted connections.

Browser-level proxy configuration

The cleanest approach is a dedicated browser profile or extension rather than system-wide proxy settings. FoxyProxy is the standard extension for this. You configure a Burp proxy entry (127.0.0.1:8080) and toggle it on when testing.

For the CA certificate:

1. With Burp running and your browser proxied through it, navigate to http://burpsuite or http://burp
2. Download the CA certificate (DER format)
3. In Firefox: Settings → Privacy & Security → Certificates → Import
4. In Chrome/Edge: Settings → Privacy & Security → Manage Certificates → Authorities → Import
5. Mark it as trusted for identifying websites

For mobile devices or thick client testing, the same certificate needs to go into the device's trust store. On Android 7+, user-installed certs are no longer trusted by apps by default — you need a rooted device or to patch the APK's network security config to test HTTPS mobile traffic.

Proxy listener configuration

The default listener at 127.0.0.1:8080 only accepts local connections. If you are proxying traffic from a mobile device or a different machine on the same network, add a listener bound to 0.0.0.0:8080 or your specific interface IP under Proxy → Proxy Listeners → Add.

For testing environments with non-proxy-aware clients (thick clients, command-line tools), enable invisible proxying: the client connects to Burp's listener IP directly, and Burp forwards using the Host header to determine the destination. Enable this per-listener under "Support invisible proxying."

HTTP History and Intercept Mode

Most of your time in Burp is spent not with interception enabled, but browsing through the HTTP History tab. Proxy → HTTP History records every request that flows through the proxy. This is your map of the application.

The workflow for a new engagement is typically:

1. Turn off intercept (Proxy → Intercept → Intercept is off)
2. Browse the application manually — log in, walk every feature, every form, every API call
3. Let the Spider or Crawler run to fill in anything you missed
4. Review HTTP History to understand the full attack surface
5. Start investigating interesting endpoints

Intercept mode — where Burp holds each request for you to inspect before forwarding — is useful for targeted manipulation of specific requests, but keeping it on continuously makes browsing unbearable. Turn it on, catch the request you care about, modify it, forward it, then turn it off again.

Filtering HTTP History effectively

In a complex application you will end up with thousands of entries. The filter bar at the top of HTTP History is essential. Useful filters:

• Show only in-scope items — add your target to scope first (right-click a request → "Add to scope") to exclude noise from CDNs and analytics
• Filter by MIME type — uncheck images, CSS, JavaScript to focus on API calls and HTML responses
• Filter by response code — 200s for successful requests, 302s to follow redirects, 403s to find blocked endpoints that might be bypassable
• Search by keyword — search for strings like token, secret, password, admin across response bodies

The Bambda filter system (introduced in Burp 2023.10) lets you write Java lambda expressions for precise filtering. For example, to find all requests containing a specific header:

requestResponse.request().hasHeader("Authorization") &&
requestResponse.request().url().contains("/api/")

Repeater: The Core of Manual Testing

Repeater is where you spend the most hands-on testing time. Send any request from HTTP History to Repeater with Ctrl+R (or right-click → "Send to Repeater"), then modify and resend it as many times as you want.

The workflow is: find an interesting parameter in HTTP History, send to Repeater, start modifying values and observe how the application responds. You are looking for:

• Error messages that reveal backend technology, query structure, or file paths
• Behavior changes when you manipulate IDs (IDOR testing)
• Differences in response time (useful for blind injection and timing attacks)
• Different responses to unexpected input types (integer vs string, negative numbers, very large values)
• Authentication/authorization enforcement — does this endpoint actually check who is calling it?

Keep multiple Repeater tabs open simultaneously — one per endpoint under investigation. Name your tabs (double-click the tab label) so you can track what you are working on.

Practical Repeater tip: compare responses

When testing authorization, send the same request twice — once as a privileged user, once as a lower-privileged user (swap the session token). If the responses are identical, you have found an authorization bypass. Send both responses to Comparer (right-click → "Send to Comparer") and Burp will highlight the differences between them.

Active Scanning with Burp Scanner (Pro)

Burp Scanner is an active vulnerability scanner that crawls and probes the application for common vulnerabilities. It is not a replacement for manual testing, but it catches a lot of low-hanging fruit and surfaces attack surface you might have missed.

Scan configurations that matter

The default scan configuration is a reasonable starting point but there are a few adjustments worth making for most engagements:

Under Scan → New Scan → Scan Configuration:

• Crawl strategy: "Fastest" is good for quick surface mapping; "Most complete" is slower but finds more endpoints through JavaScript analysis and form interaction
• Maximum link depth: increase from the default 10 to 20+ for deep applications
• Audit checks: deselect "JavaScript analysis" if you are in a time-constrained test and the JS codebase is massive — it can consume hours
• Insertion points: by default Burp tests parameters, headers, and cookies. For API testing, also enable testing within JSON values and XML element content
• Intrusion detection evasion: if the target has a WAF, enable "Use HTTPS for all requests" and consider enabling payload encoding options

Scan queue management

Rather than scanning the whole application at once, send specific requests to the scanner. Right-click any request in HTTP History or Repeater → "Scan" → choose active or passive. This gives you targeted scanning of high-value endpoints without burning time on static assets.

Passive scanning runs automatically on all proxied traffic without sending any additional requests. It catches issues like missing security headers, information disclosure in responses, and insecure cookie flags. Enable it and leave it running — it costs nothing in terms of traffic to the target.

Intruder: Fuzzing and Brute Force

Intruder automates sending modified versions of a request with a payload list. It is used for credential brute force, parameter fuzzing, enumeration, and finding injection points. In Community edition it is throttled; in Pro it runs at full speed.

Attack types

Intruder has four attack types — understanding which to use is the core skill:

• Sniper: One payload set, one insertion point at a time. Use for fuzzing a single parameter with a wordlist (e.g., testing one username field with a password list, or one parameter with an injection payload list).
• Battering ram: One payload set applied to all insertion points simultaneously. Use when you want the same payload in multiple locations at once (e.g., testing if a value reflected in both a parameter and a header causes XSS in either).
• Pitchfork: Multiple payload sets, iterated in parallel. Use for credential stuffing where you have username:password pairs — position 1 takes usernames from list 1, position 2 takes passwords from list 2, they advance together.
• Cluster bomb: Multiple payload sets, all combinations. Use for brute force where you want every combination of two lists — every username against every password. Gets large fast (1000 usernames x 1000 passwords = 1,000,000 requests).

Setting up an Intruder attack

Send a request to Intruder with Ctrl+I. In the Positions tab, Burp highlights parameters it thinks are interesting. Clear all (to start fresh) and manually select the positions you want to fuzz by highlighting them and clicking "Add."

For a basic parameter fuzzing attack on a login endpoint:

POST /api/v1/login HTTP/1.1
Host: target.example.com
Content-Type: application/json

{"username":"admin","password":"§PASSWORD§"}

In the Payloads tab, load your wordlist. For password attacks, use SecLists' Passwords/xato-net-10-million-passwords-10000.txt as a starting point. For parameter fuzzing, Fuzzing/fuzz-Bo0oM.txt covers a wide range of injection patterns.

In the Settings tab, configure:

• Grep - Match: add strings that indicate success (e.g., "Welcome", "dashboard", "token") so you can quickly identify successful requests
• Grep - Extract: pull values from responses (e.g., CSRF tokens, session IDs) for use in subsequent requests
• Redirections: set to "Always" if login success is indicated by a redirect
• Request engine: increase concurrent requests if the target can handle it and you are authorized for aggressive testing

Turbo Intruder for high-speed fuzzing

When you need more speed or more control than standard Intruder offers, Turbo Intruder (a BApp extension) is the answer. It uses a Python script to define the attack logic and can send tens of thousands of requests per second. It is particularly useful for race condition testing where request timing matters:

# Turbo Intruder script for race condition testing
def queueRequests(target, wordlists):
    engine = RequestEngine(endpoint=target.endpoint,
                           concurrentConnections=30,
                           requestsPerConnection=100,
                           pipeline=True)

    # Send 50 identical requests simultaneously
    for i in range(50):
        engine.queue(target.req, gate='race1')

    # Fire all queued requests at once
    engine.openGate('race1')

def handleResponse(req, interesting):
    table.add(req)

The gate mechanism holds requests until you call openGate, firing them all simultaneously — this is how you test whether a single-use coupon can be redeemed multiple times, or whether a balance check can be bypassed.

Key Extensions Worth Installing

Burp's BApp Store has hundreds of extensions. Most are not worth your time. These are the ones professional pentesters actually use.

Logger++

Advanced logging and filtering for all proxied traffic. More powerful search than the built-in HTTP History, with regex filtering and the ability to log to a SQLite database. Essential for large engagements where you need to query traffic programmatically.

Param Miner

Discovers unlinked parameters in requests using wordlists. Particularly useful for finding hidden parameters that the application accepts but does not expose in its normal UI — these are often where authorization bypasses and mass assignment vulnerabilities live. Also used for web cache poisoning research (it was developed by James Kettle at PortSwigger specifically for that research).

# Param Miner usage: right-click a request in HTTP History
# Extensions > Param Miner > Guess params
# It will attempt GET/POST parameter injection with a wordlist
# and flag any parameters that change the response

ActiveScan++

Extends Burp Scanner with additional checks not in the default scanner: CORS misconfiguration detection, cached HTTPS response issues, host header injection, SMTP header injection, and several others. Install it and it runs automatically alongside the built-in scanner.

J2EEScan

If you are testing Java-based applications (Spring, Struts, JBoss, WebLogic, JBoss), J2EEScan adds Java-specific checks to the scanner: deserialization payloads, EL injection, Spring Boot Actuator exposure, Struts2 remote code execution checks, and more.

JWT Editor

Replaces the older JWT Attacker extension with a full JWT manipulation toolkit. Decodes JWTs inline in the request editor, lets you modify claims, sign with your own key or attempt none-algorithm attacks, and includes one-click attacks for common JWT vulnerabilities (alg:none, RS256/HS256 key confusion).

Hackvertor

In-request encoding and transformation. When you need to apply multiple encoding layers — base64 of URL-encoded of HTML-encoded — Hackvertor lets you do it inline in the request editor using tags. Enormously useful for WAF bypass testing:

<@base64><@urlencode><script>alert(1)</script></@urlencode></@base64>

Freddy, Deserialisation Scanner

Detects and exploits insecure deserialization vulnerabilities in Java and .NET. Passively flags potentially dangerous deserialization points and actively tests them with known gadget chains from ysoserial (Java) and ysoserial.net (.NET).

Burp Collaborator for Out-of-Band Detection

Many vulnerabilities — blind SSRF, blind XXE, blind SQL injection, DNS rebinding — do not produce visible responses in the application. You need out-of-band detection: inject a payload that causes the server to make an external connection, then check if that connection arrived.

Burp Collaborator provides this. It gives you a unique subdomain (abcdef.burpcollaborator.net) and monitors it for DNS lookups and HTTP/HTTPS connections. Use "Copy to clipboard" from the Collaborator client to get your unique payload URL, inject it into a parameter, then click "Poll now" to check for interactions.

For blind SSRF testing:

POST /api/fetch-url HTTP/1.1
Host: target.example.com
Content-Type: application/json

{"url": "http://YOUR-COLLABORATOR-PAYLOAD.burpcollaborator.net/ssrf-test"}

If the application fetches that URL server-side, you will see a DNS lookup and HTTP request in your Collaborator client — confirming SSRF even when the response body gives nothing away.

For blind XXE:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE foo [
  <!ENTITY xxe SYSTEM "http://YOUR-COLLABORATOR-PAYLOAD.burpcollaborator.net/xxe">
]>
<root><data>&xxe;</data></root>

If you are using Burp Community or prefer self-hosted infrastructure, interactsh (github.com/projectdiscovery/interactsh) is an open-source alternative you can run yourself.

Scanning Authenticated Sessions: Macros

Most interesting vulnerabilities are behind authentication. Getting Burp Scanner to test authenticated endpoints requires telling it how to maintain a valid session. This is done through Burp macros.

A macro is a recorded sequence of requests that Burp re-runs before (or during) scanning to get a fresh session token or CSRF token. The setup is under Settings → Sessions → Macros.

Setting up a session handling rule

1. Go to Settings → Sessions → Session Handling Rules → Add
2. In the rule actions, add "Run a macro"
3. Record the macro: Burp replays your login sequence and extracts the session cookie or token
4. In "Parameter handling," tell Burp to update the Cookie header (or Authorization header) with the extracted value
5. Set the scope of the rule to apply to the Burp Scanner tool against your target URL

For applications using CSRF tokens, extend the macro to also fetch the page containing the CSRF token and extract it, then inject it into scanner requests. This is configured in the macro editor under "Configure item" → "Custom parameter locations."

Testing with multiple privilege levels

For authorization testing, configure multiple sessions — one as a privileged user, one as a regular user — and use the "Match and replace" rules or separate Repeater tabs to swap between them. The Authorization extension (BApp) automates this: it repeats every request with an alternative session token and flags responses where the status code or body length suggests unauthorized access succeeded.

Decoder and Comparer

Decoder is straightforward: paste any encoded value and apply decoding transformations (URL, HTML, Base64, hex, gzip, and others). Chain multiple transformations. Useful for quickly decoding session tokens, obfuscated parameters, or encoded payloads to understand what the application is actually processing.

Comparer does byte-level or word-level diff between two pieces of data. Send two responses from Repeater to Comparer to see exactly what changed. Practical uses:

• Comparing successful vs. failed login responses (for username enumeration — a subtle difference in response body often reveals whether the username exists)
• Comparing responses from two different user roles to find authorization bypass
• Comparing two versions of a token or encoded value to understand the encoding format

Sequencer: Analyzing Token Randomness

Sequencer statistically analyzes the randomness of tokens — session cookies, CSRF tokens, password reset tokens. If the token generation is weak (predictable, low entropy, or based on timestamps), Sequencer will surface it.

To use it: right-click a response containing a token in HTTP History → "Send to Sequencer." Tell Sequencer exactly where in the response the token lives (via a custom location or cookie name), then let it collect several hundred tokens through live capture (it will keep requesting the endpoint) or load tokens you collected manually.

The result is an FIPS test analysis with an effective entropy estimate in bits. Anything below 64 bits is worth investigating further. Password reset tokens should have at least 128 bits of effective entropy — anything less is potentially predictable.

Burp vs Automated Scanners: Knowing When to Use What

Burp is a manual testing platform with automation capabilities bolted on. Its scanner is good — better than most open-source alternatives — but it is not designed to replace a purpose-built automated scanner for coverage and scale.

Where Burp excels:

• Deep manual investigation of specific endpoints
• Complex multi-step vulnerabilities (chained SSRF + redirect + cookie theft)
• Business logic flaws that require understanding context
• Authentication bypass and session management testing
• One-off targeted attacks during an engagement

Where Burp Scanner falls short compared to automated platforms:

• Coverage at scale: scanning 50 microservices or an API with 300 endpoints requires automation that Burp's manual workflow does not scale to well
• CI/CD integration: Burp Enterprise can do this, but the price jump is steep; lighter automated scanners integrate more easily into pipelines
• Consistent, repeatable scanning: manual Burp sessions vary based on who ran them and what they clicked on; automated scanners hit the same surface every time
• Breadth of checks: specialized tools (Nuclei with template libraries, nikto, specific framework scanners) cover vulnerability classes Burp misses

The professional approach is layered: automated scanning as your baseline coverage (catching the common, well-defined vulnerabilities reliably and repeatably), with Burp for manual investigation of anything interesting the automated scan surfaces, and for testing the business logic that only a human can reason about.

Practical Workflow for a Web App Pentest

Putting it together, here is the workflow most experienced pentesters use for a web application engagement:

Phase 1: Reconnaissance and surface mapping

1. Configure browser proxy, install CA cert
2. Add target to Burp scope
3. Browse the application manually with intercept off — log in, use every feature, note what parameters and endpoints exist
4. Run Burp Crawler to find anything you missed
5. Use Param Miner on key endpoints to discover hidden parameters

Phase 2: Passive analysis

1. Review HTTP History with filters — look for interesting patterns: tokens in URLs, verbose error messages, sequential IDs, admin-looking endpoints
2. Check passive scanner findings — missing headers, insecure cookies, information disclosure
3. Decode and analyze session tokens in Sequencer
4. Note all parameterized endpoints for active testing

Phase 3: Active testing

1. Send interesting endpoints to Burp Scanner for active scanning
2. Manually test IDOR candidates in Repeater — swap IDs, compare responses
3. Test authentication endpoints with Intruder — username enumeration, rate limiting bypass
4. Inject Collaborator payloads in parameters that might trigger server-side requests
5. Test file upload endpoints, XML parsers, and template engines manually

Phase 4: Exploitation and chaining

1. For confirmed vulnerabilities, develop proof-of-concept in Repeater
2. Look for chains — can a reflected XSS be elevated using a CSRF bypass? Can an IDOR be combined with SSRF?
3. Use Turbo Intruder for race conditions on sensitive operations
4. Document all findings with request/response pairs (Burp's "Save item" function or copy as curl)

Tips for Efficiency

Keyboard shortcuts: Learn Ctrl+R (send to Repeater), Ctrl+I (send to Intruder), Ctrl+Shift+P (send to Comparer), Ctrl+U (URL encode selection), Ctrl+B (Base64 encode selection). The mouse workflow is slow.

Project files: Save your project regularly (File → Save project). Burp project files are large but contain your entire HTTP History, scanner results, Repeater tabs, and notes. Losing a project partway through an engagement is painful.

Scope management: Set scope aggressively before you start. Everything outside scope should be excluded from scanning and ideally from HTTP History too. It keeps the noise down and ensures you are not accidentally scanning systems you are not authorized to test.

Match and replace rules: Under Proxy → Match and Replace, you can automatically modify all proxied requests. Useful for: always stripping If-None-Match headers (to prevent 304 responses that hide content), adding a custom header to all requests, or replacing a hardcoded IP with a hostname.

Copy as curl: Right-click any request in HTTP History or Repeater → "Copy as curl command." This gives you a complete curl command you can paste into a terminal, share with a colleague, or include in a report. Far faster than manually reconstructing the request.

Annotations: Right-click any request in HTTP History and add a comment or highlight color. Use this aggressively — mark interesting requests yellow, confirmed vulnerabilities red, already-tested paths grey. Your HTTP History becomes a working document, not just a log.

Common Pitfalls

Forgetting to scope before scanning: Burp Scanner will follow external links and scan third-party systems if you do not set scope. You can end up scanning Google's OAuth endpoints or your customer's CDN — systems you have no authorization to test.

Trusting the scanner completely: Burp Scanner has false negatives. Missing a vulnerability in a scanner report does not mean it is not there. The scanner is a starting point, not a conclusion.

Not testing with multiple roles simultaneously: Most authorization bugs only appear when you switch roles. Keep two browser profiles open — one as admin, one as regular user — and actively compare what each can access.

Ignoring passive findings: Pentesters focus on active exploitation and often dismiss passive findings as low severity. Missing security headers and insecure cookie flags can be exploited in combination with other weaknesses.

Not saving evidence as you go: Build the habit of exporting request/response pairs for every finding immediately. Do not rely on memory or trying to reproduce it later. Right-click → "Save item" saves a full Burp XML file with the complete request and response.

Burp Suite takes time to master. The tool's power is less about memorizing every menu option and more about developing intuition for what is interesting in an HTTP exchange — the parameter that should not be user-controlled, the response that reveals too much, the timing difference that suggests a blind injection. The mechanics of Burp are learnable in a week; the judgment about what to do with it takes years.

For teams that need professional-grade security scanning without requiring every developer to become a Burp expert, automated platforms built on the same underlying techniques — Kali tooling, active probing, authenticated scanning — provide consistent coverage across your entire attack surface on demand.