Burp Suite tutorial for beginners: step by step in your own lab

Burp Suite is a proxy that sits between your browser and a web application, so you can see, pause, change and replay every HTTP request the browser sends. In this tutorial you’ll run the free Community Edition against OWASP Juice Shop on your own machine, and by the end you’ll have intercepted a login, replayed a search in Repeater, run a small Intruder attack and decoded a session token.

Everything here runs locally. Legal note: only test systems you own or have written permission to test. Juice Shop on your own laptop qualifies; a random website does not.

What you need before you start

• Burp Suite Community Edition. It’s free from PortSwigger’s download page. On Kali Linux it’s usually preinstalled; run burpsuite from a terminal or find it under Web Application Analysis.
• Docker, to run the target application.
• A vulnerable practice app. We’ll use OWASP Juice Shop, a deliberately insecure web shop maintained by OWASP for training. DVWA (Damn Vulnerable Web Application) works too, and the same Burp steps apply.

Start Juice Shop:

$ docker run --rm -p 3000:3000 bkimminich/juice-shop
...
info: Server listening on port 3000

Open http://localhost:3000 in a normal browser to confirm it loads. If you’d rather use DVWA, docker run --rm -p 8081:80 vulnerables/web-dvwa serves it on port 8081 (log in, then click “Create / Reset Database” on the setup page).

If you haven’t built a lab yet, our guide to setting up a cybersecurity home lab covers VMs, networking and keeping practice targets off your home network.

Step 1: Set up the Burp proxy

When you launch Burp Community, choose Temporary project (the Community Edition doesn’t save projects to disk) and Use Burp defaults. Burp starts a proxy listener on 127.0.0.1:8080. Confirm it under Proxy → Proxy settings: you should see that address with the Running box ticked.

You now have two ways to send browser traffic through Burp.

Option A: Burp’s built-in browser (easiest)

Go to Proxy → Intercept and click Open browser. This is a Chromium browser that Burp preconfigures to use its proxy and trust its certificate. For a first session, this is the least fiddly route and it handles localhost without extra settings.

Option B: Your own browser (Firefox)

Using your own browser is worth learning, because you’ll need it for mobile testing and some client environments later.

1. In Firefox, open Settings → Network Settings → Settings...
2. Choose Manual proxy configuration, set HTTP Proxy to 127.0.0.1, port 8080, and tick Also use this proxy for HTTPS.
3. Firefox doesn’t send localhost traffic through a proxy by default. Type about:config in the address bar, search for network.proxy.allow_hijacking_localhost and set it to true.

Many testers install a proxy-switcher extension such as FoxyProxy so they can toggle Burp on and off without digging through settings.

Step 2: Install Burp’s CA certificate

For HTTPS sites, Burp decrypts traffic by presenting its own certificate to your browser, signed by a certificate authority (CA) that Burp generates uniquely for your installation. Your browser will throw security warnings until it trusts that CA.

Juice Shop on http://localhost:3000 is plain HTTP, so you don’t strictly need this for today. You will need it the moment you test anything over HTTPS, so do it now:

1. With Burp running and Firefox proxied, visit http://burpsuite.
2. Click CA Certificate in the top-right corner. This downloads cacert.der.
3. In Firefox, go to Settings → Privacy & Security → Certificates → View Certificates → Authorities → Import.
4. Select cacert.der, tick Trust this CA to identify websites, and click OK.

PortSwigger’s guide to installing Burp’s CA certificate has instructions for Chrome and other browsers.

A safety habit: this CA can sign certificates for any site, so it only belongs in a browser profile you use for testing. Create a separate Firefox profile (about:profiles) for Burp work, and never install the certificate in your everyday browser.

Step 3: Intercept and read your first request

In Juice Shop, register a test account with a throwaway address such as student@lab.test and a lab-only password. Then:

1. In Burp, go to Proxy → Intercept and switch Intercept on.
2. In the browser, log in to Juice Shop.
3. The browser hangs, because Burp is holding the request. You’ll see something like this:

POST /rest/user/login HTTP/1.1
Host: localhost:3000
Content-Type: application/json
Content-Length: 55
Origin: http://localhost:3000
Referer: http://localhost:3000/

{“email”:“student@lab.test”,“password”:“Lab-Passw0rd!”}

Read it line by line. The method and path (POST /rest/user/login) tell you this is the login API. The JSON body carries the credentials. There’s no CSRF token and no cookie yet. Click Forward to let it through, then switch Intercept off. Leaving intercept on is the most common beginner frustration: the browser seems to freeze because every request is waiting for you.

Now open Proxy → HTTP history. Every request the browser made is logged here, including all the API calls the page made in the background. Click the login request and look at the response:

HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8

{“authentication”:{“token”:“eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiJ9.eyJzdGF0dXMiOiJzdWNjZXNzIiwiZGF0YSI6eyJpZCI6MjIs...”,“bid”:6,“umail”:“student@lab.test”}}

That token is a JSON Web Token (JWT). Keep it in mind; we’ll take it apart in Decoder.

Tip: use Target → Scope to add http://localhost:3000 to scope, then filter HTTP history to show only in-scope items. On real engagements, scope keeps you inside what the client authorised.

Step 4: Replay and modify requests with Repeater

Repeater lets you edit a request and send it again as many times as you like, watching how the server responds. It’s where most manual web testing happens.

Use the Juice Shop search box to search for apple. In HTTP history, find this request:

GET /rest/products/search?q=apple HTTP/1.1
Host: localhost:3000

Right-click it and choose Send to Repeater (or press Ctrl+R). In the Repeater tab, click Send. The response is JSON listing matching products:

HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8

{“status”:“success”,“data”:[{“id”:1,“name”:“Apple Juice (1000ml)”,“description”:“The all-time classic.”,“price”:1.99, ...}]}

Now change the parameter to a single quote, q=', and send again. Instead of an empty result, Juice Shop returns an HTTP 500 error, and the response body includes a database error that mentions SQLITE_ERROR (exact wording varies by version). A single quote breaking the query is a classic sign that user input is being placed straight into a SQL statement. That’s injection, one of the categories in the OWASP Top 10, and our post on the OWASP Top 10 explained with examples covers why it happens.

You don’t need to exploit it today. The skill is the loop: change one thing, send, compare. Try q=apple'-- and q=apple'))-- and note how each response differs. Write down what you observe; that habit becomes the evidence section of a pentest report.

Step 5: Automate guesses with Intruder (basics)

Intruder takes a request, marks one or more positions in it, and fills those positions with payloads from a list. It’s used for brute-forcing, fuzzing parameters and enumerating IDs.

Community Edition limitation: Intruder is rate-throttled in the free version, so attacks run slowly. Keep payload lists short. PortSwigger’s Intruder documentation explains each attack type.

Let’s run a tiny password guess against your own test account:

1. In HTTP history, right-click the POST /rest/user/login request and Send to Intruder (Ctrl+I).
2. In the Intruder tab, highlight the password value inside the JSON and click Add §. It should look like this:

{“email”:“student@lab.test”,“password”:“§Lab-Passw0rd!§”}

3. Leave the attack type as Sniper (one payload set, one position at a time).
4. In the Payloads panel, add a short list: password, 123456, letmein, Lab-Passw0rd!, admin123.
5. Click Start attack.

Results appear in a new window. Sort by Status code or Length:

(Lengths are illustrative; yours will differ.) The one request with a different status and length is the hit. Reading the difference between responses, rather than the content of each one, is the core Intruder skill.

The four attack types in brief:

On a real engagement, check the rules of engagement before any brute-forcing. Account lockouts can take real users offline.

Step 6: Decode data with Decoder

Web apps encode data constantly: URL encoding, Base64, HTML entities, hex. Decoder converts between them.

Copy the JWT from the login response and paste it into Decoder. A JWT is three Base64url-encoded parts separated by dots: header, payload and signature. Paste just the first part:

eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiJ9

Choose Decode as → Base64:

{“typ”:“JWT”,“alg”:“RS256”}

Now decode the second part (the payload). In Juice Shop you’ll see your user record, starting {“status”:“success”,“data”:{“id”:22,..., and it includes a password hash field. Putting a password hash inside a token that the browser can read is a deliberate Juice Shop flaw, and it’s exactly the kind of thing a tester notes. (If Decoder complains, the segment may need = padding added at the end; Base64url omits it.)

Two more Decoder exercises worth trying:

• Encode ' OR 1=1-- as URL. Decoder encodes every character, so you’ll get %27%20%4f%52%20%31%3d%31%2d%2d. (In Repeater, select text and press Ctrl+U to encode only key characters, which is closer to what a browser sends.)
• Decode YWRtaW46TGFiLVBhc3N3MHJkIQ== as Base64. You’ll get admin:Lab-Passw0rd!, which is how HTTP Basic authentication carries credentials. It’s encoded, not encrypted.

The Smart decode button guesses the encoding for you, which helps when you don’t recognise a format.

A 20-minute practice routine

Once the basics work, repeat this on Juice Shop or DVWA a few times a week:

1. Browse the whole app with intercept off and let HTTP history fill up.
2. Pick three requests that take user input and send them to Repeater.
3. For each, change one parameter at a time (quotes, very long strings, negative numbers, another user’s ID) and note any change in status, length or error.
4. Pick one login or ID parameter and run a five-payload Intruder attack.
5. Decode every token or odd-looking string you find.
6. Write two lines per finding: what you sent, and what came back.

PortSwigger’s free Web Security Academy has guided labs built for Burp, which make a natural next step after Juice Shop. If you’re mapping out the wider skill set, see how to become a penetration tester from scratch.