A Complete Guide to Burp Suite
If you watch an experienced web application tester work, one program is open the entire time. Not their code editor, not their terminal. Burp Suite. It runs in the background capturing everything the browser does, and every time the tester wants to poke at the application, they reach for it.
The reason is simple. A web browser is built to use an application. Burp is built to interrogate it. The browser hides the machinery: the requests, the headers, the cookies, the parameters. Burp puts all of that in your hands and lets you change any of it before it reaches the server. That is the whole game in web security: the application trusts data coming from the browser, and Burp lets you send data the browser never would.
This guide covers the parts you will actually use, in the order you will meet them, with a workflow that ties them together. I am not going to walk through every menu. I am going to show you how the tool is used.
What it actually is
Burp Suite is a collection of tools that share one thing: they all operate on HTTP traffic between you and a web application. The traffic flows through Burp’s proxy, and from there you can pass any request into the other tools. That shared pipeline is what makes it a “suite” rather than a handful of separate programs.
There are two editions worth knowing. Community is free and gives you the manual tools, which is most of what matters when you are learning. Professional adds an automated scanner and removes the speed limits, and it is what you buy once testing is your job. Everything in this guide works in Community unless I say otherwise.
Download it from PortSwigger, install it, and launch a temporary project with the default settings. You are in.
Step one: getting traffic into Burp
Nothing works until Burp can see your browser’s traffic, and this is exactly where most beginners stall for an afternoon. There are two ways.
The easy way: Burp’s built-in browser. Modern Burp ships with a pre-configured Chromium browser. Go to the Proxy tab, click Open Browser, and you get a browser that already routes through Burp and already trusts its certificate. Nothing to configure. For learning, just use this.
The manual way: your own browser. If you want to use your normal browser, you point it at Burp’s proxy (127.0.0.1:8080 by default) and then deal with HTTPS. Here is the part people miss: because Burp intercepts encrypted traffic, your browser will scream about invalid certificates until you tell it to trust Burp. With Burp running, visit http://burp, download the CA certificate, and import it into your browser as a trusted authority. Once that is done, HTTPS sites load cleanly and you can read every encrypted request.
Either way, the test is the same: browse to your target, switch to Burp, and look at the HTTP history sub-tab under Proxy. If you see a growing list of requests, you are set. If it is empty, your traffic is not reaching Burp. Fix that before doing anything else.
A note before you go further: only ever point Burp at applications you are allowed to test. The obvious practice targets are OWASP Juice Shop, DVWA, and PortSwigger’s own free Web Security Academy labs. Those exist precisely so you can break things without breaking the law.
The Proxy: watch, then interrupt
The Proxy is the heart of the suite. Everything else is fed from here.
In its passive mode, it simply logs traffic. Browse the application normally (log in, click around, submit a form) and watch the HTTP history fill up. This alone is educational: you see how many requests one page load actually makes, what cookies are flying back and forth, which endpoints handle what. Spend time here before you touch anything. You cannot test an application you do not understand, and reading its real traffic is how you learn it.
Then there is Intercept, the mode that makes Burp famous. Turn it on, and Burp pauses each request before it leaves your machine and holds it for your inspection. You can read it, edit any part of it, then forward it, or drop it entirely.
This is the exact moment web hacking clicks for people. You add an item to a shopping cart with a price of £50. You intercept the checkout request. You change 50 to 1. You forward it. If the server never re-checks the price, you just bought a £50 item for a pound. The browser would never let you send that. Burp does, because Burp answers to you, not to the application’s JavaScript.
Intercept is powerful but it interrupts your browsing, so most people leave it off while mapping the app and flip it on only when they want to catch a specific request.
Repeater: the tool you’ll use most
Once you have found an interesting request in the history, right-click it and Send to Repeater. This is where you will spend most of your time.
Repeater does one deceptively simple thing: it lets you send a single request, see the response, tweak the request, and send it again, as many times as you like, without touching the browser. Every hypothesis in manual testing gets answered here.
The workflow is a loop. Change one thing, send, read the response, learn something, change the next thing. Suppose a URL is GET /profile?id=1005. You send it in Repeater and see your own profile. You change it to id=1006 and send again. If someone else’s profile comes back, you have just found an access control flaw: the app trusts the ID you supply without checking it belongs to you. That single test, repeated across a handful of IDs, is one of the most common and most valuable findings in the whole field. (It has a name, IDOR, and it is worth understanding in depth.)
Repeater is deliberate and manual. That is its strength. You are thinking about each request, reading each response carefully, building an understanding of how the application behaves. When you want to do the same test hundreds of times, you switch tools.
Intruder: automation for one request
Intruder takes a single request and fires many variations of it. Send a request to Intruder, and Burp lets you mark positions: the exact spots in the request you want to vary. Then you attach a payload list, and Burp replays the request once per payload, swapping it into your marked positions.
The classic uses:
- Testing a login for weak passwords. Mark the password field, load a list of common passwords, and let Intruder try each one. Watch the response sizes: a successful login usually looks different from a failure.
- Fuzzing a parameter. Mark a value and throw a list of special characters and injection strings at it to see which ones break something.
- Enumerating values. Mark an ID and count upward to find which records exist.
The skill that matters here, exactly as with ffuf, is reading the results. Burp shows you the status code, response length and time for every attempt. The one that behaves differently is the one that matters: a different length on a login attempt often means you got in. Sort by the length column and the outlier jumps out.
One honest caveat: in the free Community edition, Intruder is deliberately throttled to a crawl. It is fine for learning the concept and for small lists. Serious Intruder work is a Professional feature, and for pure content or parameter discovery, ffuf is faster anyway.
The supporting cast
A few smaller tools round out the daily workflow:
Decoder encodes and decodes data: URL encoding, Base64, HTML entities, hex, and hashing. Web apps are full of encoded values, and half the battle is turning %2Fetc%2Fpasswd back into something readable, or Base64-decoding a token to see what is inside it. You will paste things into Decoder constantly.
Comparer shows you the exact differences between two pieces of data: two responses, two tokens, two error messages. When you make a small change and the response almost looks the same, Comparer highlights precisely what shifted. Invaluable for spotting subtle behaviour, like whether a valid and invalid username produce responses that differ by a single word (a username enumeration bug).
Sequencer analyses how random a set of tokens really is: session cookies, password reset tokens, anything the app expects to be unguessable. If Sequencer finds a pattern, an attacker might predict the next token. This one you reach for less often but it is the right tool when session tokens look suspiciously tidy.
And in Professional, the Scanner crawls and automatically tests the application for a broad range of issues. It is a genuine time-saver, but treat it as a first pass that flags leads for a human to confirm: automated scanners produce false positives and miss the logic flaws that pay the best.
Extending Burp
One reason Burp stays dominant is that you can bolt extra tools onto it. The BApp Store, built into Burp’s Extensions tab, is a catalogue of free add-ons written by the community, and a few of them are close to essential once you are working seriously.
Some highlight interesting things in traffic automatically; some add new attack capabilities; some just make tedious tasks faster. You do not need any of them to learn, and piling on extensions before you understand the core tools is a common beginner distraction that adds noise without adding skill.
The honest advice is: learn Proxy, Repeater and Intruder cold first. Add extensions later, one at a time, when you hit a specific task that one solves. An extension you do not understand is just clutter in your workflow; an extension that fixes a problem you actually have is a genuine upgrade. Let your needs pull them in, rather than installing a dozen because a video told you to.
A workflow that ties it together
Here is how the pieces fit on a real, authorised engagement:
- Map the application. Proxy on, Intercept off. Browse everything: every page, every form, every role. Let the HTTP history build a full picture of the app’s surface.
- Study the traffic. Read the requests. Note where IDs, tokens, prices, roles and file paths appear. These parameters are your targets.
- Pick a target and go manual. Send an interesting request to Repeater. Change one parameter at a time. Watch how the app responds.
- Scale up when it’s worth it. When one manual test suggests a pattern (weak IDs, a guessable parameter), move to Intruder (or ffuf) to test it at volume.
- Decode and compare as you go, using Decoder and Comparer to understand tokens and spot subtle differences.
- Confirm and record. Once you have proven a flaw, capture the exact request and response as evidence. A good finding is reproducible; Burp gives you the raw proof.
The tools you meet elsewhere in the toolkit slot straight into this: ffuf for content discovery before you start, SQLmap when a parameter looks injectable, and the concepts from the OWASP Top 10 telling you what to test for.
Mistakes to avoid early
- Skipping the mapping phase. People rush to Intercept and start changing things before they understand the app. Browse first. The findings come from understanding, not from clicking Intercept.
- Leaving Intercept on and getting confused. With Intercept on, every request pauses, including background ones, and it feels like the browser has frozen. Turn it off when you are just browsing.
- Not installing the CA certificate. Half the “Burp isn’t working” problems are HTTPS trust problems. Use the built-in browser to sidestep it entirely while you learn.
- Treating the scanner as the whole job. Automated scanning finds the easy stuff. The valuable findings (access control, business logic, chained bugs) come from a human in Repeater.
- Testing without permission. Burp makes it trivially easy to attack any site you visit. Do not. Stick to lab targets and authorised scopes.
Where to go next
Burp Suite rewards time spent in it more than almost any tool in security. The concepts (intercept, replay, modify, automate) are the concepts of web hacking itself, and once they are second nature you will read any application’s behaviour fluently.
The single best way to learn it is PortSwigger’s own free Web Security Academy: it is built by the people who make Burp, it is genuinely excellent, and every lab is legal to break. When you want a structured checklist of what to test once you are comfortable, the OWASP Web Security Testing Guide is the reference the industry actually uses. Pair that with the OWASP Top 10 guide to know what you are hunting for, and the bug bounty roadmap to put it to work.
If you would rather learn with structure, live sessions and someone to answer your questions, that is what our training provides: Burp and the full web-testing workflow, taught hands-on.
