Burp Suite Tutorial for Kali Linux (2026)

What is Burp Suite?

Burp Suite is the industry-standard tool for web application security testing. Made by PortSwigger (the same people who built the free Web Security Academy), it's used by professional bug bounty hunters, web pentesters, and AppSec engineers.

The current version as of 2026 is Burp Suite 2026.4, which now ships as a combined installer for both Community Edition (free) and Professional (paid). The Community Edition is what's pre-installed on Kali Linux — it's missing the active scanner and some convenience features but has every manual testing tool you need to learn. It's one of the essential Kali Linux tools for web application security.

How Burp Suite Actually Works

Burp Suite is a man-in-the-middle (MITM) proxy. The flow:

1. You configure your browser to send all HTTP/HTTPS traffic through Burp instead of directly to the internet (default: 127.0.0.1:8080)
2. When you click a link or submit a form, your browser sends the request to Burp
3. Burp either passes the request through, holds it for your inspection (intercept mode), or lets you copy it into other tools
4. Burp forwards the request to the target server and gets the response
5. The response goes back through Burp to your browser

For HTTPS, Burp generates a self-signed CA certificate that your browser trusts (once you install it). This lets Burp decrypt HTTPS traffic on the fly — the same technique corporate firewalls use for SSL inspection, except in your hands instead of IT's.

Installing Burp Suite

Kali ships with Burp Suite Community Edition pre-installed. Just launch it:

On first launch, you'll see a dialog asking about temporary vs disk-based projects. Community Edition only supports temporary projects, so just click "Next" through the defaults.

Installing the latest version manually

Kali's repos sometimes lag behind PortSwigger's releases. If you want the absolute latest:

Browser Setup — The Critical First Step

Burp can't intercept what doesn't go through it. You have two options: use Burp's pre-configured browser, or configure your own.

Option 1: Burp's built-in browser (easiest)

Burp ships with a customized Chromium browser that's pre-configured to use Burp's proxy and trust Burp's certificate. To launch it:

1. In Burp, go to the Proxy tab
2. Click the Open browser button
3. A new Chromium window opens, ready to use

This is the path of least resistance — zero setup, works immediately. For most learners, this is the right choice. Use your regular browser for normal web browsing; use Burp's browser for testing.

Option 2: Configure your own browser (Firefox, Chrome)

If you want to use your existing Firefox or Chrome, you need to do two things: route traffic through Burp's proxy, and install Burp's CA certificate.

For HTTPS sites to work without certificate errors, install Burp's CA cert:

1. With Burp running, visit http://burpsuite (or http://burp) in your proxy-configured browser
2. Click CA Certificate in the top right to download cacert.der
3. In Firefox: Settings → Privacy & Security → View Certificates → Authorities → Import. Check "Trust this CA to identify websites."
4. In Chrome on Linux: use NSS database tools (see PortSwigger's docs)

Setting Up a Practice Target

Before going further, you need something legal to attack. The fastest options:

PortSwigger Web Security Academy (recommended)

Free, browser-based, no setup. Labs are designed specifically around Burp Suite features. Each lesson explains a vulnerability, gives you a lab environment, and walks through the solution.

Sign up at portswigger.net/web-security. Start with "SQL injection — Lab #1" — it's the canonical first lab.

DVWA (Damn Vulnerable Web Application)

Self-hosted PHP app. Runs in Docker or directly on Kali. Adjustable difficulty levels (Low, Medium, High, Impossible) make it ideal for progression.

OWASP Juice Shop

Modern single-page Angular app with 100+ challenges. Best for practicing on a realistic codebase.

The Proxy Tab — Where Everything Starts

The Proxy is the heart of Burp. Every test starts here.

Intercept on/off

The big button at the top of the Proxy tab. When ON, every request from your browser pauses at Burp until you forward it. When OFF, requests flow through but are still logged in HTTP history.

When to use Intercept ON: When you specifically need to modify a request before it's sent (e.g., changing a price in a checkout flow, tampering with a hidden field).

When to use Intercept OFF: Almost all the time. You can review requests after the fact in HTTP history, and you avoid the frustration of having to forward every single request your page makes (modern pages make dozens).

HTTP history (your most-used tab)

The Proxy → HTTP history sub-tab logs every request and response that passes through Burp. Right-click any entry to send it to other tools:

• Send to Repeater (Ctrl+R) — modify and resend manually
• Send to Intruder (Ctrl+I) — automate payload-based attacks
• Send to Comparer — diff this response against another
• Send to Decoder — decode encoded payloads

Modifying requests on the fly

With Intercept ON, when a request is paused:

1. You see the raw HTTP request in the Request pane
2. Edit anything — headers, parameters, cookies, body
3. Click Forward to send your modified version
4. Click Drop to cancel the request entirely

Example: a hidden form field <input type="hidden" name="price" value="49.99">. You can't change it in the browser easily, but in Burp you can intercept the POST request and change price=49.99 to price=0.01. If the backend trusts the client-side value (and many do), you just bought a $50 item for a penny.

Repeater — The Workhorse

Repeater is the tool you'll use most. It lets you take a single request, modify any part of it, and resend it as many times as you want — seeing the response immediately each time.

Workflow:

1. Find a request in Proxy → HTTP history
2. Right-click → Send to Repeater (or press Ctrl+R)
3. Switch to the Repeater tab
4. Edit the request, click Send, see the response
5. Edit again, send again — iterate until you understand the behavior

What Repeater is great for

• Testing SQL injection — modify a parameter, send, see if you get a database error or different content
• Probing access controls — change a user ID from 1234 to 1235, see if you get someone else's data (IDOR)
• Testing input validation — try special characters, oversized inputs, null bytes, see what crashes or behaves unexpectedly
• Bypassing rate limits — change session tokens, IP headers, user agents
• Manual XSS testing — try payload variations until one isn't filtered

Repeater pro moves

Intruder — Automated Attacks

Intruder takes one request, defines "positions" within it, and substitutes payloads from a wordlist into those positions. It's how you automate everything: brute-forcing logins, fuzzing parameters, enumerating user IDs.

The four attack types

Example: brute-forcing a login form

1. Submit a fake login attempt with username "admin" and password "test" in your practice target
2. In Proxy → HTTP history, find the POST request and send it to Intruder
3. In Intruder → Positions: Burp auto-detects parameters. Click Clear § to remove all positions, then highlight just the password value and click Add §
4. Attack type: Sniper
5. Payloads tab: paste a wordlist (e.g., rockyou.txt's top 1000) or use Burp's built-in lists
6. Click Start attack
7. In the results window, sort by Length. Different-length responses usually mean different outcomes — a successful login likely has a different size than failures

The Supporting Tools

Decoder

Decode and encode strings in URL, HTML, Base64, ASCII hex, hex, Octal, Binary, Gzip formats. Plus hash generation (MD5, SHA-1, SHA-256, etc.). Constantly useful for unwrapping encoded payloads or generating obfuscated test inputs.

Comparer

Diffs two pieces of data (usually responses). Sends them to a side-by-side view that highlights differences in words or bytes. Essential when probing for blind SQL injection where you're looking for a subtle difference between "true" and "false" responses.

Sequencer

Analyzes the randomness of session tokens, CSRF tokens, password reset codes — anything that should be unpredictable. Generates statistical confidence scores. Useful when you suspect a token is predictable (and therefore forgeable).

Target → Site map

As you browse a target, Burp builds a tree of every URL it's seen. Helps you understand the application's structure and identify endpoints you haven't tested yet.

Real Walkthrough — SQL Injection on DVWA

Let's put it all together. Assumes you have DVWA running on localhost:8080 with security set to Low.

Step 1: Find the vulnerable endpoint

In DVWA, go to SQL Injection. The form takes a User ID. Submit "1" and observe the response shows user details.

Step 2: Capture the request in Burp

With your browser proxied through Burp, the GET request appears in Proxy → HTTP history:

Step 3: Send to Repeater and probe

Right-click → Send to Repeater. Try modifying the id parameter:

Step 4: Extract the data

Once you've confirmed injection, iterate in Repeater to enumerate database structure (information_schema queries), then extract data. Each modified request is one click in Repeater.

This entire workflow takes 30 seconds once you're fluent. Burp's value is the speed of iteration — try a payload, see the response, refine, try again.

Working with HTTPS

By default, you'll see HTTPS connection errors until you install Burp's CA certificate. The fix:

1. Make sure Burp is running and your browser is using it as a proxy
2. In the browser, visit http://burpsuite (the magic Burp landing page)
3. Click CA Certificate in the top right — downloads cacert.der
4. Import the cert into your browser's certificate store as a trusted CA

Extensions Worth Installing

Burp's extensibility is one of its best features. Install extensions from Extensions → BApp Store:

• Logger++ — better request logging with advanced filtering
• Autorize — automated authorization testing (find IDORs at scale)
• Param Miner — discovers hidden parameters via heuristic analysis
• Active Scan++ — extra payloads for the active scanner (Pro only)
• JSON Web Tokens — decode and tamper with JWTs natively
• Hackvertor — advanced encoding/decoding (Decoder on steroids)
• Turbo Intruder — much faster than built-in Intruder, scriptable in Python (works in Community)

Burp Suite vs. Other Tools

Burp vs. OWASP ZAP

ZAP is the free, open-source alternative to Burp. It's improved a lot and is competitive for many tasks. Differences:

• Burp — better UX, more polished, industry standard, paid Professional tier
• ZAP — free forever, fully open-source, more aggressive automated scanning, better for CI/CD pipelines

If you're learning web app testing professionally, learn Burp (it's what every employer asks for). If you're doing automated security testing in a pipeline, ZAP is the better fit.

Burp vs. Wireshark

Both inspect traffic, but at different layers. Wireshark is a passive packet analyzer that sees raw network frames (Ethernet, TCP, UDP, etc.). Burp is an HTTP-specific interception proxy that lets you actively modify requests before they're sent. For web app testing: Burp. For protocol-level network analysis: Wireshark. They complement each other.

Burp vs. curl/Postman

curl and Postman are great for crafting individual requests, but they don't capture browser traffic. You'd have to manually copy each request from browser dev tools. Burp captures everything automatically, then lets you replay/modify in Repeater — much faster for security testing workflows.

Burp Suite for Bug Bounty

Burp is the de facto standard for bug bounty hunting. The typical workflow:

1. Reconnaissance — use Nmap for network-level recon, then start browsing the target with Burp
2. Mapping — let Burp's site map populate as you click through the app naturally
3. Spotting opportunities — look for IDs in URLs (IDOR potential), file paths (LFI potential), forms with hidden fields (parameter tampering)
4. Manual probing — Send to Repeater, try payloads, iterate
5. Automation — Send to Intruder for parameter fuzzing, ID enumeration, brute force
6. Reporting — copy the working request out of Repeater for your proof-of-concept

For learning bug bounty seriously, PortSwigger's Web Security Academy is free and built specifically around this workflow. Working through it methodically is the single most efficient way to skill up.

Common Issues & Troubleshooting

"Connection refused" / "Proxy not responding"

Burp's proxy isn't running, or your browser is pointing to the wrong port. Check Burp's Proxy → Proxy settings tab — the listener should show 127.0.0.1:8080 with status "Running." If not, click Add and create a listener on 127.0.0.1:8080.

HTTPS certificate errors won't go away

You either didn't install Burp's CA cert, installed it for the wrong user/profile, or didn't check "Trust this CA to identify websites." Reinstall, verify in your browser's certificate manager, restart the browser.

I see no traffic in HTTP history

Three possible causes: (1) your browser isn't actually using Burp's proxy (test by visiting http://burpsuite — should show Burp's landing page), (2) you have a system-level proxy bypass for localhost (some VPN apps do this), or (3) the Proxy → HTTP history filter is hiding traffic — check the filter bar at the top.

Intercept is too noisy with browser background traffic

Two fixes: (1) set up Target → Scope and check "Drop all out-of-scope traffic" in Proxy settings, (2) use Burp's pre-configured browser only for testing, not general browsing.

Intruder is way too slow

You're on Community Edition (rate-limited). Either upgrade to Professional, or install Turbo Intruder extension which bypasses the throttle.