Burp Suite basics: proxy, repeater and a safe testing workflow

Burp Suite lets you see and edit the requests your browser sends. Learn the core tools and a calm workflow that keeps you in scope.

A proxy sitting between a browser and a server

Burp Suite is an intercepting proxy: it sits between your browser and a website, so you can see every request and response, pause them, and edit them. It is the standard tool for manual web testing. The free Community Edition is enough to learn.

Set it up

  1. Install Burp Suite Community and start a temporary project.
  2. Burp listens on a local port (commonly 127.0.0.1:8080).
  3. Point your browser to use that proxy. The built-in Burp browser makes this easy.
  4. Install Burp's CA certificate in the browser so it can show HTTPS traffic.
  5. Set the target scope to the program's in-scope domains, so Burp ignores everything else and you do not touch out-of-scope hosts by mistake.

The core tools

Proxy. With interception on, each request pauses so you can read or change it before forwarding. Turn interception off for normal browsing, and use the HTTP history tab to see everything that passed through.

Repeater. The most-used tool. Send a request from history to Repeater, change one thing (a parameter, a header, an ID), press Send, and compare the responses. This is how you test ideas one step at a time.

Target / Site map. A tree of the hosts and paths your browsing discovered. It helps you see the structure of the application.

Decoder. Converts data between formats such as URL encoding, Base64 and hex.

Comparer. Shows differences between two responses, useful for authorization tests (response for user A vs user B).

Intruder. Automates sending many variations of a request. In the Community Edition it is rate limited. Use it only where the program permits automation, and slowly.

A safe workflow

  1. Browse the whole app normally with Burp recording. Use every feature as a regular user.
  2. Read the HTTP history. List the interesting requests: those with IDs, file names, redirects or role-related fields.
  3. Send one to Repeater and form a hypothesis, for example "does this endpoint check that the invoice belongs to me?"
  4. Test with your own two accounts. Change one thing at a time.
  5. Compare responses. If you see a difference that matters, reproduce it twice.
  6. Stop when you have proof, and write the report.

Habits that help

  • Name and save interesting requests to a notes file or Burp's comments.
  • Use filters in HTTP history to hide images, CSS and noise.
  • Keep the scope list updated. Check before you send a request to a new host.
  • Mind the rate. Do not hammer a server.
  • Never test on accounts or data that are not yours.

Common beginner mistakes

  • Forgetting to turn interception off and thinking the site is broken.
  • Testing out-of-scope hosts because scope was not set.
  • Changing many things at once, so you cannot tell what mattered.
  • Running automated tools without reading the program's rules.

Takeaway: use Burp's Proxy to observe, Repeater to test one change at a time, and the scope setting to stay in bounds. Practise first on a deliberately vulnerable lab app.


Bug Bounty series, Part 2 (recon and tools): 3 of 5. Previous: Reading a web app's JavaScript to understand how it works.

Keep reading