Burp Suite for Beginners — A 2026 Hands-On Walkthrough

Burp Suite is the single tool that defines modern web application testing. If you can drive Burp confidently you can deliver 80% of a web pentest. This walkthrough takes a complete beginner from installation to finding a real authorization bug, using the latest 2026 UI and the workflow our AppSec consultants actually use on engagements.

Install and configure (5 minutes)

1. Download Burp Suite Community from PortSwigger and start it
2. Open the embedded Chromium browser via 'Open Browser' — it pre-trusts Burp's CA so you skip cert warnings
3. If you prefer Firefox, install the FoxyProxy add-on and point it at 127.0.0.1:8080
4. Visit http://burpsuite and download the CA cert; import to Firefox under Settings → Privacy → Certificates → Authorities
5. Make a single HTTPS request and confirm it appears in Proxy → HTTP history

The five Burp tools you actually use

Your first workflow — find a BOLA bug

BOLA (Broken Object Level Authorization, OWASP API #1) is the most common high-severity finding in modern apps. Here's how to find one in 10 minutes on any app with numeric IDs.

1. Log in as User A. Browse the app. Find any endpoint with a numeric ID like /api/orders/4012
2. Right-click the request in Proxy → HTTP history → Send to Repeater
3. In Repeater, change the ID to 4011 and Send. Did the response come back? You may already have BOLA
4. To prove it, log in as User B in a separate browser. Note your Cookie / Authorization header
5. Send User A's request again with User B's session — if you get User B's data back, document it
6. Move to Intruder to enumerate IDs and quantify the blast radius

GET /api/orders/4011 HTTP/2
Host: api.target.com
Authorization: Bearer eyJ... (User A's token)
Accept: application/json

# Mutate ID, leave the token alone
# Then mutate the token, leave the ID alone
# Combinations of both = the BOLA matrix

Intruder for parameter fuzzing

Send the BOLA request to Intruder. Mark the ID parameter with the § markers. Use Sniper attack with a Numbers payload from 1 to 5000, step 1. Sort the results by response length — outliers tell you which IDs returned data.

Collaborator — finding what you can't see

Burp Collaborator gives you a unique DNS / HTTP server to detect blind vulnerabilities. If you inject your Collaborator URL into a parameter and the target's server makes a DNS lookup back to it, you've found SSRF / blind XXE / blind RCE.

POST /api/avatars/import HTTP/2
Host: target.com

{"url": "http://abc123.oastify.com"}

# Then check Collaborator → Poll now for a hit

Extensions every tester installs

• Autorize — automated authorization checks across two sessions (BOLA at scale)
• JWT Editor — decode, edit, re-sign JWTs in Repeater
• Param Miner — finds hidden GET / POST / header parameters
• Hackvertor — encoding chains (great for WAF bypass)
• Logger++ — searchable history with regex filters
• Active Scan++ — extra checks (CSTI, host header, blind SSRF)

The 8 mistakes new testers make

1. Testing in production without scope — get written approval first
2. Not turning off intercept and forgetting why nothing loads
3. Running Active Scan against authenticated state without a session handling rule
4. Using Intruder against rate-limited APIs and getting their account locked out
5. Forgetting to disable upstream proxies before testing internal IPs
6. Saving Burp project to a network share — corrupts on disconnect
7. Not exporting the project file (.burp) before reformat / OS upgrade
8. Treating a 200 response as a vulnerability without verifying the data returned