Burp Suite for Web Application Security Testing: Community Edition Guide

What Burp Suite Does

Burp Suite acts as an intercepting proxy between your browser and the web server. Every HTTP request your browser makes passes through Burp, which captures it, lets you inspect it, modify it, and replay it.

This interception capability is the foundation of web application security testing. It lets you:

• See exactly what your browser sends (including hidden form fields, cookies, and tokens)
• Modify requests before they reach the server (to test input validation)
• Replay requests with different payloads (to test for injection vulnerabilities)
• Fuzz parameters automatically (to find unexpected behavior)

Installation

Download Burp Suite Community Edition from PortSwigger's website. It runs on macOS, Windows, and Linux (requires Java 17+).

On macOS:

brew install --cask burp-suite

Or download the installer directly from portswigger.net/burp/communitydownload.

Proxy Setup

Burp's proxy listens on 127.0.0.1:8080 by default.

Browser Configuration

Firefox — go to Settings → Network Settings → Manual proxy configuration:

• HTTP Proxy: 127.0.0.1
• Port: 8080
• Also use for HTTPS: checked

Chrome — use a proxy extension like Proxy SwitchyOmega, or launch Chrome with:

google-chrome --proxy-server="http://127.0.0.1:8080"

Install Burp's CA Certificate

For HTTPS interception, install Burp's CA certificate:

1. With your browser proxied through Burp, visit http://burpsuite
2. Click "CA Certificate" to download cacert.der
3. In Firefox: Settings → Certificates → View Certificates → Authorities → Import
4. In Chrome: Settings → Security → Manage Certificates → Import

After installing the certificate, Burp can intercept HTTPS traffic without certificate errors.

Configuring Scope

Add your target to scope to filter out noise:

1. Go to Target → Site Map
2. Right-click your target domain → "Add to scope"
3. Go to Proxy → Intercept and click "Open browser" to use Burp's embedded Chromium

Configure Burp to only intercept in-scope requests:

• Proxy → Options → Intercept Client Requests: check "And URL Is in target scope"

Core Tools

Proxy Intercept

The Proxy Intercept tab pauses each request so you can inspect and modify it before forwarding:

1. Enable interception: Proxy → Intercept → Intercept is on
2. Browse your application
3. Burp pauses on each request — inspect the raw HTTP
4. Modify any field (parameters, headers, body)
5. Click "Forward" to send the modified request

HTTP History

Proxy → HTTP History shows all captured requests. Right-click any request to:

• Send to Repeater (for manual testing)
• Send to Intruder (for automated fuzzing)
• Send to Scanner (Pro only)
• Copy as curl command

Repeater

Repeater lets you manually modify and replay requests:

1. Send a request to Repeater (right-click → "Send to Repeater")
2. Modify any part of the request (parameters, headers, method, body)
3. Click "Send" to see the response
4. Compare responses to identify vulnerabilities

Example — testing a parameter for SQL injection:

Original request:

GET /products?id=42 HTTP/1.1
Host: example.com

Modify and test:

GET /products?id=42' HTTP/1.1

GET /products?id=42 OR 1=1-- HTTP/1.1

GET /products?id=42; DROP TABLE products-- HTTP/1.1

If the error response changes (database error message, different content length, different status code), that's a signal worth investigating.

Intruder

Intruder automates payload injection across hundreds or thousands of values:

1. Send a request to Intruder
2. Highlight the parameter to fuzz → click "Add §" to mark it as an injection point
3. Go to the Payloads tab → select payload type:
   • Simple list: paste or load a wordlist
   • Numbers: sequential numbers (useful for IDOR testing)
   • Brute forcer: character combinations
4. Click "Start attack" to run all payloads

Community Edition throttles Intruder (one request per second). For speed, use Professional Edition or supplementary tools like ffuf.

Common Intruder use cases:

• IDOR testing: fuzz an object ID parameter with sequential numbers to find unauthorized access
• Username enumeration: test login endpoint with a list of usernames, look for different response times or messages
• Password spraying: try a common password against many usernames
• Header injection: test for Host header injection, response splitting

Testing OWASP Top 10 with Burp

A01: Broken Access Control

Test for Insecure Direct Object References (IDOR):

1. Log in as User A, capture a request that accesses a resource: GET /api/orders/1234
2. Send to Intruder, mark the order ID as an injection point
3. Use Numbers payload to try IDs in sequence: 1000–2000
4. Look for 200 responses — these are IDs you shouldn't have access to

Test for forced browsing:

1. Browse the application as a regular user
2. Look for admin URLs in the site map: /admin, /api/admin/users
3. Send these requests in Repeater and observe whether access is granted

A02: Cryptographic Failures

Look for sensitive data in transit:

1. In HTTP History, filter for requests containing sensitive terms: password, credit_card, ssn
2. Check that all sensitive endpoints use HTTPS
3. Inspect cookies — they should have Secure and HttpOnly flags

A03: Injection

Test for SQL injection in every input field:

' 
''
'--
' OR '1'='1
1 UNION SELECT null,null,null--

Signs of SQL injection:

• Database error messages (MySQL, PostgreSQL error format)
• Different response length for 1 vs 1'
• True/false based responses (1 OR 1=1 returns all results, 1 OR 1=2 returns normal)

A07: Identification and Authentication Failures

Test session token entropy:

1. Log in multiple times, capture the session token each time
2. Compare tokens — they should be high-entropy and unpredictable

Test for session fixation:

1. Get a session token before login
2. Log in
3. Check if the session token changed — it should after authentication

Test for predictable password reset tokens:

1. Request a password reset
2. Request another reset
3. Compare token format — sequential or timestamp-based tokens are exploitable

A08: Software and Data Integrity Failures

Check for sensitive data in JavaScript files:

1. In the site map, review all JavaScript files
2. Look for API keys, internal URLs, and debugging code left in production bundles

Saving and Sharing Findings

Export HTTP traffic for reporting:

1. Proxy → HTTP History → select requests → right-click → "Save items"
2. Save as a Burp XML file for documentation

Create notes in User Options → Project notes to track findings during testing.

Running Burp in CI (Headless)

Burp Suite Pro has a CLI mode for CI integration. For Community Edition, use OWASP ZAP as a free alternative for automated CI scanning. See the SAST/DAST guide for CI-focused security scanning tools.

Responsible Use

Burp Suite is a security testing tool. Only test applications you own or have explicit written permission to test. Unauthorized security testing is illegal in most jurisdictions.

For testing your own web application during development, pair Burp with:

• A dedicated test environment (not production)
• Test accounts with realistic but fake data
• Scope configuration to prevent accidental testing of third-party systems

Summary

Burp Suite Community Edition provides the core tools for web application security testing:

1. Proxy — intercept and inspect all browser traffic
2. Repeater — manually modify and replay requests
3. Intruder — automate payload injection for fuzzing
4. Target/Site Map — understand your attack surface

Start with scope configuration, browse the application, then use Repeater for targeted manual testing of suspicious endpoints. Use Intruder for IDOR testing and input fuzzing. Document findings with request/response pairs captured in HTTP History.