PWNMI

Guides

Burp Suite Fundamentals: Intercepting and Testing Web Traffic

Updated July 22, 2026 · Written by PWNMI — see About.

If Nmap tells you what's running, Burp Suite is how you actually test a web application once you know there's one to test. It sits between your browser and the target as a proxy, letting you see, intercept, and modify every request before it goes out.

Setup

  1. Download Burp Suite Community Edition (free) from PortSwigger — it's more than enough to learn on.
  2. Configure your browser to proxy through Burp: default is 127.0.0.1:8080. Firefox with a dedicated proxy profile is the common choice, since it keeps Burp traffic separate from your normal browsing.
  3. Install Burp's CA certificate in your browser so HTTPS traffic can be decrypted and inspected, not just HTTP.

The core workflow

Burp's tabs map to a natural testing flow:

  • Proxy — intercept and view every request/response as it happens
  • Repeater — take a captured request, tweak it, resend it, and compare responses. This is where most manual testing actually happens.
  • Intruder (rate-limited in Community Edition) — automate sending variations of a request, useful for testing parameters against a wordlist
  • Target/Site map — builds a map of the application as you browse it, so you have a structured view of what's been covered

A basic test flow

  1. Turn on Intercept, browse the target normally, and let requests flow into Burp's history.
  2. Find an interesting request — a login form, a parameter that looks like it maps to an ID, a file upload.
  3. Right-click → Send to Repeater.
  4. In Repeater, modify the request (change a parameter value, remove a header, alter a cookie) and resend it. Compare the response against the original.
  5. If something looks promising — an error message that leaks information, a response that changes based on an ID you don't own — that's a lead worth digging into further.

What to actually look for

  • Broken access control — change an ID parameter (?id=104 → ?id=105) and see if you get another user's data back
  • Verbose error messages — stack traces or SQL errors that leak internal detail
  • Missing security headers — no Content-Security-Policy, no X-Frame-Options
  • Client-side trust — anything enforced only in JavaScript (price, role, permission) and not re-checked server-side

This maps directly onto the OWASP Top 10, which is worth reading alongside this if you haven't already.

Common mistakes

  • Never installing the CA cert, so all HTTPS traffic is invisible to Burp — the single most common setup mistake for beginners.
  • Running Intruder like a blunt brute-force tool against anything and everything. It's rate-limited in the free edition for a reason, and hammering a target you don't have explicit authorization to load-test can look a lot like a denial-of-service attack.
  • Testing without authorization. Everything here assumes a target you own, a lab VM, or a platform (TryHackMe, HackTheBox, an in-scope bug bounty program) that has explicitly authorized this kind of testing.

Next step

For shortcuts and secondary tabs (Decoder, Comparer, Match and Replace) once the core workflow is comfortable, see the Burp Suite Cheat Sheet. Practice this against a deliberately vulnerable app — OWASP Juice Shop or a beginner web room on TryHackMe are both good starting points. See Labs for specific write-ups.