Intercepting Traffic with Burp Suite: Your First Web Test
Burp Suite is where manual web testing starts. This beginner walkthrough shows how to intercept and edit your first request, read the HTTP history, resend it in Repeater, and run a safe first test against a lab app.
Burp Suite is the intercepting proxy that sits between your browser and a web application, and learning to drive it is the first real step from clicking through a site to testing it. Every request your browser sends can be paused, read, changed, and sent on, which means you stop trusting what the page shows you and start looking at the raw traffic underneath. This walkthrough is for a complete newcomer: by the end you will have caught your first request, edited it, resent it, and watched the server answer differently because of what you changed.
Work through it once in order to build the habits, then keep it open while you practise. Everything here happens against a lab you run yourself or are explicitly allowed to test, never a live site you do not own.
Point Burp Suite only at an application you own or have written permission to assess, such as OWASP Juice Shop on your own machine or the practice target at lab.0xpriv.dev. Intercepting and tampering with traffic to a site you do not control is illegal in most places, even if the bug is obvious.
01What an intercepting proxy actually does
An intercepting proxy parks itself in the middle of the conversation between your browser and the server, so every request stops at Burp Suite before it continues. Normally your browser talks straight to the web server and you only ever see the finished page. With a proxy in the path, each request and each response passes through a tool you control, where you can read it, hold it, edit it, or drop it entirely.
This is why manual web testing centres on the proxy. The page is just a rendering of data the server sent; the interesting decisions, such as which user id to load or whether a price is trusted, happen in the request parameters and headers that the browser hides from you. Seeing and changing those is the whole game.
Burp Suite Community edition, the free version, gives you everything you need for this: the Proxy, the HTTP history, the site map, Repeater, and a rate-limited Intruder. That is more than enough to learn on.
02Installing Burp Suite Community and the one-time setup
Installing Burp Suite Community takes a few minutes, and the one-time setup is mostly accepting sensible defaults. Download the installer for your platform from the PortSwigger site, run it, and launch Burp. The Community edition is free, bundles its own Java runtime, and asks nothing beyond a click to continue.
On first launch, choose a temporary project and the default Burp settings. Burp then starts a proxy listener on 127.0.0.1:8080, which is the address your browser traffic needs to flow through. You can confirm the listener under the Proxy settings, where it is shown as running and bound to the loopback address.
Install and open Burp
Run the Community installer, then start Burp and pick a temporary project with default settings.
Confirm the proxy listener
Open Proxy settings and check that a listener is running on 127.0.0.1:8080. That is the gate your traffic goes through.
Choose how the browser reaches Burp
Use Burp's built-in browser, which is already configured, or point your own browser at the 127.0.0.1:8080 proxy.
The fastest path for a beginner is Burp's own pre-configured browser. On the Proxy tab there is an "Open browser" button that launches an embedded Chromium already set to proxy through Burp and already trusting Burp's certificate, so HTTPS sites load without any warning. If you prefer your everyday browser instead, set its proxy to 127.0.0.1 port 8080 for HTTP and HTTPS, which is the part that takes one extra step for encrypted sites.
$ curl -s -x http://127.0.0.1:8080 http://lab.0xpriv.dev/ -o /dev/null -w "%{http_code}\n" 200 $ # the request now also appears in Burp's HTTP history
If anything about proxy settings or certificates feels fiddly, use the built-in browser from the Proxy tab. It removes two whole setup steps and behaves like a normal Chromium window.
03Trusting Burp's CA certificate for HTTPS
Trusting Burp's certificate authority is the step that makes HTTPS sites work through your own browser. To read encrypted traffic, Burp generates a fresh certificate for each site on the fly, signed by a local CA that is unique to your install. Your browser has never heard of that CA, so until you tell it to trust the certificate, every HTTPS page shows a security warning.
With your browser already proxying through Burp, visit http://burp and use the "CA Certificate" link to download the DER file. Then import it into your browser's or operating system's trusted authorities. In Firefox you add it under the certificate settings and tick the option to trust it for websites; on Windows or macOS you add it to the system trust store so Chromium-based browsers pick it up.
# download Burp's CA while your browser is proxying through Burp # then import cacert.der into your browser or OS trust store curl -s -x http://127.0.0.1:8080 http://burp/cert -o cacert.der file cacert.der
A trusted CA can sign a certificate for any site. Import Burp's CA only on a machine you use for testing, keep it off your daily driver if you can, and remove it when you are done learning if the machine is shared.
04Your first intercept: catch, read, forward or drop
Your first intercept is the moment the tool clicks. On the Proxy tab there is an Intercept sub-tab with a toggle; switch it to "Intercept is on". Now load a page in the proxied browser. Instead of the page appearing, it hangs, because the request is sitting in Burp waiting for you.
What you see is the raw HTTP request: the method and path on the first line, then the headers, then any body. This is exactly what your browser was about to send, with nothing hidden. Read it top to bottom until the shape feels familiar.
GET /rest/products/search?q=apple HTTP/1.1 Host: lab.0xpriv.dev User-Agent: Mozilla/5.0 Accept: application/json Cookie: session=4f1a2b...; lang=en Connection: close
You have three choices for the held request. "Forward" sends it on unchanged, and the page finishes loading as normal. "Drop" throws it away, so the browser never gets its answer. Or you can edit the request right there in the panel before forwarding it, changing a header, a cookie, or a parameter and watching what comes back. For now, forward a few requests and get comfortable with the flow.
Leaving intercept on means every single request, including images and scripts, stops and waits. Most of the time you browse with intercept off and read traffic afterwards in the HTTP history, flipping it on only when you want to catch one specific request.
05Reading the HTTP history and the site map
The HTTP history is the running log of everything that passed through the proxy, and it is where you spend most of your time. Find it under Proxy, HTTP history. Each row is one request and response pair, with the method, URL, status code, length, and timing. Click a row and the lower panels show the full request and the full response, so you can study traffic you already let through without holding anything up.
The site map, under the Target tab, organises the same data differently. It builds a tree of every host, folder, and endpoint Burp has seen, so you get a structural view of the application instead of a time-ordered log. Browsing the app with intercept off quietly fills both views, which is the easy way to map what an application exposes.
| View | What it is good for |
|---|---|
| HTTP history | Time-ordered log of every request; find the exact call a button triggered |
| Site map (Target) | Tree of hosts and endpoints; see the shape of the whole application |
| Intercept | Hold one live request to read or edit before it is sent |
A useful first habit: do one action in the app, such as searching or logging in, then open the HTTP history and find the request that action produced. Learning to connect a click in the browser to a row in the history is most of what manual testing is.
06Editing and resending in Repeater
Repeater is the tool for editing a request and sending it again as many times as you like, which is where real testing begins. Find an interesting request in the HTTP history, right-click it, and choose "Send to Repeater". The request opens in the Repeater tab in an editable panel, with an empty response panel next to it.
Change something in the request, press "Send", and the response appears on the right. Change it again, send again, and compare. Because you control the exact bytes, you can ask precise questions: what happens if this id is a different number, if this parameter is removed, if this value is far longer than expected, or if a cookie is missing. The server answers each time, and the differences are the signal you are hunting for.
GET /rest/products/search?q=apple HTTP/1.1 Host: lab.0xpriv.dev Accept: application/json Cookie: session=4f1a2b...; lang=en Connection: close # in Repeater, change q=apple to q=apple' and send again # then watch the status code and body change
# q=apple -> 200 OK, normal JSON list of products # q=apple' -> 500 Internal Server Error, a database error in the body a different response to a single changed character is the whole point
Repeater is manual and deliberate, one request at a time, which makes it the right place to understand a single endpoint deeply before you automate anything. Most beginners overuse automation and underuse Repeater; resist that and spend time here.
07A quick look at Intruder and Community edition throttling
Intruder is Burp's tool for sending the same request many times with parts of it swapped out, which is simple automation for tasks like trying a list of values. You mark positions in the request, give it a set of payloads, and it replays the request once per payload, collecting the responses in a table you can sort by status or length.
The catch in the free version is deliberate throttling. Community edition runs Intruder at a reduced, artificially slowed speed, so a run that would take seconds in the paid edition takes far longer. That is fine for a handful of values while you learn the mechanics, and painful for anything large. For bulk work people either upgrade or script the same idea themselves.
# 0xpriv.dev/labs # the same idea as Intruder, written by hand against a lab target: # send one request per candidate id and note the ones that return data import requests base = "http://lab.0xpriv.dev/rest/basket/" headers = {"Authorization": "Bearer eyJ..."} # your own token from the lab for bid in range(1, 10): r = requests.get(base + str(bid), headers=headers) print(bid, r.status_code, len(r.content))
For this first web test, you do not need Intruder at all. It is listed here so you know what it is and why the free edition feels slow, not because you should reach for it yet.
08Scoping the target so you do not proxy the whole internet
Setting a target scope keeps Burp focused on the one application you are allowed to test, instead of logging every analytics beacon and update check your browser makes. Without scope, the HTTP history fills with noise from dozens of unrelated hosts, and it is easy to send a stray request somewhere you never intended.
Open the Target tab, go to Scope, and add your lab host, for example lab.0xpriv.dev or http://localhost:3000 if you run the app yourself. Then tell Burp to act on in-scope items only. You can set the proxy to drop or ignore out-of-scope traffic and set the HTTP history filter to show in-scope only. From then on, Burp works on your target and stays quiet about everything else.
Add the host to scope
Target, Scope, Add, and enter your lab host such as lab.0xpriv.dev.
Limit tools to in-scope
Set the proxy and the HTTP history filter to in-scope only, so stray hosts never clutter the view or get touched.
Sanity-check the filter
Browse for a minute and confirm only your target shows up in the history. If other hosts appear, tighten the scope.
09A worked first test: tampering a parameter on a lab app
A worked first test ties every step together: intercept a request, change one parameter, and watch the application hand you data you were not meant to see. The target here is a copy of OWASP Juice Shop, reachable in this walkthrough at lab.0xpriv.dev (or http://localhost:3000 if you run it yourself). Juice Shop is built to be tested, so this is a safe place to make mistakes.
Log in to the lab as your own user and open your basket. With the proxy recording, that action produces a request to fetch the basket by its numeric id. Find it in the HTTP history and send it to Repeater. The request looks like this, with your session token and your own basket id:
GET /rest/basket/1 HTTP/1.1 Host: lab.0xpriv.dev Authorization: Bearer eyJhbGciOi... Accept: application/json Connection: close
Now change the basket id from 1 to 2 in Repeater and send it. If the application checks only that you are logged in, and not that the basket actually belongs to you, it happily returns someone else's basket. That gap, where an object id can be changed to reach data that is not yours, is one of the most common real web flaws, and you just found it by editing a single number.
# GET /rest/basket/1 -> 200 OK, your basket, your items # GET /rest/basket/2 -> 200 OK, another user's basket and items same session, different id, data that should have been denied
Write down what you changed, the request, and the response. That note is the start of a finding: what you did, what you expected, and what actually happened. On a real authorized engagement, that is the evidence a report is built from.
Juice Shop ships its own data and is meant to be broken. Changing an id on your own copy affects only fake accounts you control. The same keystrokes against a live site you do not own would be unauthorized access, which is exactly what the scope rule exists to prevent.
10Staying safe and in scope
Staying safe is less about tooling and more about discipline, and it matters from your very first test. The techniques here are the same ones used against real applications, so the line between practice and an offence is permission, not skill. Keep that line bright with a few fixed habits.
11Detecting proxy-driven tampering from the other side
Detecting this kind of tampering is worth understanding even as a beginner attacker, because it shows why the flaw is the real problem, not the proxy. From the defender's seat, a user whose requests walk through object ids one by one, or whose client sends values the official front end never offers, stands out in the application logs. A sudden run of /rest/basket/1, /rest/basket/2, /rest/basket/3 from one session is a classic pattern.
The fix is not to spot the proxy, which is invisible and entirely legitimate, but to build the server so a tampered request fails. Every request that loads an object should check that the logged-in user is allowed that specific object, server side, every time. When the server enforces ownership, changing the id in Repeater just returns an error, and the whole class of problem closes regardless of what tool sent the request.
12FAQ
Is Burp Suite Community edition enough to learn on?FAQ
Yes. The free Community edition includes the Proxy, HTTP history, site map, Repeater, and Intruder, which covers everything in this walkthrough and most of what a beginner needs for months. The paid edition mainly adds a faster Intruder and an automated scanner, neither of which you need while you are learning the manual workflow.
Why do HTTPS sites show a certificate warning until I import Burp's CA?FAQ
To read encrypted traffic, Burp creates its own certificate for each site, signed by a local authority your browser does not recognise. The warning is your browser doing its job. Once you import and trust Burp's CA, the browser accepts those certificates and HTTPS pages load normally through the proxy. Burp's own built-in browser already trusts it, so you can skip this step entirely by using that.
What is the difference between the Proxy intercept and the HTTP history?FAQ
Intercept holds a live request so you can read or change it before it is sent, which pauses your browsing. The HTTP history is the log of requests that already went through, which you read afterwards without stopping anything. Most of the time you browse with intercept off and study traffic in the history, turning intercept on only to catch one specific request.
Why is Intruder so slow in the free version?FAQ
Community edition deliberately throttles Intruder to a reduced speed. It is fine for a few values while you learn, but slow for anything large. For a first web test you do not need Intruder at all; Repeater, one request at a time, is where the learning happens.
Can I get in trouble for testing a site with Burp Suite?FAQ
Yes, if you test a site you do not own and have no permission for. The techniques are legal to practise, but running them against someone else's application without authorization is unauthorized access and a crime in most countries. Keep every test on a lab you run or a target you have written permission to assess.
references
Founder of 0xpriv, covering offensive security, web application vulnerabilities, and practical security research through PHP, Python, and hands-on technical analysis.