Burp Suite is the industry-standard web application security testing tool. It sits between your browser and web servers, allowing you to inspect, modify, and replay HTTP requests. For security professionals, Burp Suite is essential for finding and exploiting web vulnerabilities.
The Community Edition is free and sufficient for learning. This guide covers setup, proxy configuration, interception, and practical testing techniques.
What Is Burp Suite?
Burp Suite is a proxy and testing platform that enables you to:
- Intercept requests: Modify HTTP before it reaches the server
- Intercept responses: Modify server responses before browser displays them
- Replay requests: Resend modified requests to test behavior
- Crawl applications: Map site structure and discover endpoints
- Scan for vulnerabilities: Automated testing (Pro feature, some in Community)
- Intruder attacks: Brute force parameters and discover injection points
Installation
Download:
Visit https://portswigger.net/burp/community-edition
Select your OS (Windows, macOS, Linux).
Linux installation:
chmod +x burpsuite_community_v2024.x_linux_x64.sh
./burpsuite_community_v2024.x_linux_x64.sh
Follow the installer.
macOS:
Download the DMG, drag Burp Suite to Applications.
Windows:
Download the EXE installer, run it.
Launch Burp Suite:
/usr/bin/burpsuite
Or find it in your applications menu.
Initial Setup
First launch:
Burp asks about temporary/persistent projects. For learning:
- Select Temporary project (simplest, no saving required)
- Click Start Burp
You’ll see the main window with four tabs:
- Proxy: Intercept and modify traffic
- Target: Site mapping and scope
- Tools: Scanner, Intruder, Repeater, etc.
- Extender: Community extensions
Configuring the Proxy
Step 1: Start Burp Proxy
- Go to Proxy tab
- Click Proxy settings (gear icon)
- Ensure Listen on all interfaces is checked
- Default port: 8080
This makes Burp listen for browser traffic on port 8080.
Firefox (easiest to configure per-browser):
- Settings → Network Settings
- Scroll to Proxy
- Select Manual proxy configuration
- HTTP Proxy: 127.0.0.1
- Port: 8080
- Check Use this proxy for all protocols
- Click OK
Chrome/Chromium:
google-chrome --proxy-server="127.0.0.1:8080"
Or use system proxy settings (same as Firefox above, applies system-wide).
Step 3: Accept CA Certificate
First request through Burp:
- Navigate to any HTTPS website in your configured browser
- Browser shows certificate warning (Burp MITM certificate)
- Accept the warning
Install Burp’s CA certificate permanently (to avoid warnings):
- Navigate to
http://burp in browser
- Click CA Certificate button
- Download cacert.der or cacert.pem
- Install as trusted certificate (varies by browser/OS)
Firefox import:
- Settings → Privacy & Security → Certificates → View Certificates
- Authorities tab → Import
- Select the Burp CA certificate
- Check Trust this CA to identify websites
- Click OK
Now HTTPS sites work without warnings.
Intercepting Requests
Basic Interception
Enable interception:
- Proxy → Intercept tab
- Click Intercept is on (toggle button)
- Open Firefox and browse normally
Every request gets intercepted before reaching the server.
Example intercepted request:
GET /login.php HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0 (X11; Linux x86_64)
Accept: text/html,application/xhtml+xml
Accept-Language: en-US,en;q=0.5
Connection: close
Cookie: PHPSESSID=abcd1234efgh5678
[empty body for GET request]
Modify the request:
Click into the request and edit directly. Common modifications:
# Change login parameters
POST /login.php HTTP/1.1
Host: example.com
Content-Length: 35
username=admin&password=any_password_here&login=1
Send the modified request:
Click Forward to send it to the server.
Intercepting Responses
Enable Intercept Response (in Intercept tab options):
The server’s response appears before the browser displays it.
Example response modification:
Original response:
HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 4523
<html>
<body>
<h1>Access Denied</h1>
<p>You do not have permission to view this page.</p>
</body>
</html>
Modify to:
HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 4523
<html>
<body>
<h1>Access Granted</h1>
<p>Welcome, admin!</p>
</body>
</html>
Click Forward. Browser displays the modified response.
This demonstrates:
- Client-side validation is meaningless
- Server must enforce security, not the browser
- Trusting the client is always a mistake
For testing requests without interception, use Repeater:
- Intercept any request
- Right-click → Send to Repeater
- Go to Tools → Repeater tab
The request appears in Repeater where you can:
- Modify parameters without browser navigation
- Resend instantly after changes
- Compare responses to different payloads
- Test authentication with different tokens
Practical example - Testing for SQL injection:
Original request:
GET /search.php?q=products HTTP/1.1
Repeat 1 (normal query):
GET /search.php?q=products HTTP/1.1
[Response: 5 products found]
Repeat 2 (with injection):
GET /search.php?q=products' OR '1'='1 HTTP/1.1
[Response: 50 products found - Database error suggests SQLi!]
Intruder automates parameter fuzzing and brute-forcing. Community Edition is rate-limited but functional.
Basic workflow:
- Intercept a request
- Right-click → Send to Intruder
- Go to Tools → Intruder
- Click Positions tab
- Select target parameter (click to highlight)
- Click Add (marks this as a variable)
- Select Payload type: Simple list
- Enter payloads (one per line)
- Click Start attack
Example - Brute force login:
Positions:
POST /login.php HTTP/1.1
...
username=admin&password=§password§&login=1
^ marked variable
Payloads:
password123
admin123
letmein
sunshine
password1
qwerty
123456
Intruder sends 7 requests, each with a different password. Responses reveal which one succeeds.
Proxy History
All requests (even without interception) appear in Proxy → HTTP history:
Request Response Method URL Status Length MIME Type
1 200 GET http://example.com/ 200 5234 HTML
2 304 GET http://example.com/css/... 304 0 CSS
3 200 GET http://example.com/api/user 200 1230 JSON
4 302 POST http://example.com/login 302 120 HTML
5 200 GET http://example.com/home 200 8945 HTML
Right-click any request:
- Send to Repeater: Edit and resend
- Send to Intruder: Fuzz parameters
- Show request in browser: View in browser
- Copy as cURL: Generate command-line equivalent
Site Mapping
Target → Site map shows the application structure.
With interception disabled but Burp listening:
example.com
├── /
├── /login.php
├── /home.php
├── /api/
│ ├── /api/users
│ ├── /api/posts
│ └── /api/comments
├── /admin/
│ ├── /admin/dashboard
│ └── /admin/users
└── /logout.php
Click endpoints to see requests/responses.
Scope setting:
Define target scope to avoid logging unrelated requests:
- Target → Scope
- Click Add and enter domain:
example.com
- Enable Use advanced scoping
- Now Burp logs only in-scope requests
Practical Testing Workflow
Testing a login form:
- Configure browser proxy (Firefox)
- Enable Burp interception
- Navigate to login form
- Fill in credentials: username=admin, password=test123
- Submit (request intercepts)
- Observe request:
POST /login.php
username=admin&password=test123
- Modify parameter: change
admin to admin' OR '1'='1
- Forward
- Observe response: SQL injection confirmed
- Send request to Repeater
- Test different payloads (UNION, SLEEP, etc.)
- Document findings
Testing hidden parameters:
- Right-click page → Inspect Element
- Look for hidden form fields:
<input type="hidden" name="csrf_token" value="abc123">
- Intercept next request
- Verify the token is included
- Modify token, forward
- Observe if server validates or accepts invalid tokens
- Indicates CSRF vulnerability if invalid token is accepted
Common Testing Scenarios
Authentication Bypass
Original request:
POST /login.php
username=admin&password=wrongpassword
Intercept, modify:
POST /login.php
username=admin' --&password=&login=1
Parameter Tampering
Original:
GET /profile.php?user_id=123
Modified:
GET /profile.php?user_id=999
Can you see another user’s profile? Indicates Broken Access Control.
Response Manipulation
Modify response to bypass client-side checks:
Original response (client blocks submission):
<input type="hidden" name="price" value="100">
<script>
function validate() {
if (price < 50) alert("Price too low!");
}
</script>
Intercept and modify:
<input type="hidden" name="price" value="1">
Purchase at $1 instead of $100.
Cookie Manipulation
Intercept request, modify session cookie:
GET /admin.php HTTP/1.1
Cookie: PHPSESSID=user_session_123
Intercept, change to admin session:
GET /admin.php HTTP/1.1
Cookie: PHPSESSID=admin_session_456
If you access admin panel, indicates session fixation/hijacking vulnerability.
Best Practices
- Document everything: Note every finding with request/response
- Use Repeater: Don’t just intercept, test systematically
- Enable scope: Don’t log traffic outside your test target
- Check cookies: Look for weak, unencrypted, or predictable session tokens
- Test all methods: GET, POST, PUT, DELETE, PATCH
- Understand flows: Follow authentication, session management, state changes
- Test error handling: How does app handle invalid input?
Conclusion
Burp Suite transforms web application security testing from guesswork to systematic discovery. The proxy intercepts every request, giving you complete visibility and control over web communication.
Community Edition provides 90% of testing capability. Master the proxy, Repeater, and Intruder, and you can find and exploit web vulnerabilities methodically.
Burp Suite is your X-ray vision for web applications. Use it to see what others miss.