Burp Suite Basics: Intercept, Repeat and Test Safely

Burp Suite is a web security testing platform that sits between a browser and a web application. It lets authorised testers inspect, modify and resend HTTP requests to understand how an application handles user input, sessions and access controls.

This guide uses an isolated practice application. Never test a public website, company system or API unless you have written permission and a clearly defined scope.

What are the Burp Suite basics?

The core Burp Suite basics are configuring the proxy, intercepting browser traffic, reviewing HTTP history and sending selected requests to Repeater. These functions help you understand normal application behaviour before checking for security weaknesses.

Important Burp tools include:

This article concentrates on Proxy, HTTP history and Repeater. These tools provide a practical foundation before learning automated testing or more advanced workflows in an Ethical Hacking course.

How does Burp Suite intercept web traffic?

Burp operates as a local HTTP proxy between your browser and the target application. The browser sends its request to Burp, Burp displays or forwards it, and the application response returns through the same path.

A diagram in words looks like this:

Browser
   |
   | HTTP or HTTPS request
   v
Burp Proxy on 127.0.0.1:8080
   |
   | Forwarded request
   v
Authorised lab application
   |
   | HTTP response
   v
Burp HTTP history -> Browser

For HTTPS traffic, Burp generates a certificate for the requested site and signs it with the Burp Certificate Authority. A browser must trust that local CA before it can display intercepted HTTPS pages without certificate warnings. This mechanism must only be used on systems you own or are authorised to assess.

When Intercept is on, each matching request pauses in Burp. You can:

• Select Forward to send the request.
• Select Drop to discard it.
• Edit a header, cookie, path or parameter before forwarding.
• Send the request to another Burp tool.

When Intercept is off, traffic continues normally but still appears in Proxy > HTTP history. Keeping interception off during ordinary navigation prevents the browser from appearing to hang.

How can you build a safe Burp Suite practice lab?

Use a deliberately vulnerable application on an isolated local machine or training network. OWASP Juice Shop, DVWA and PortSwigger Web Security Academy labs are suitable because they are designed for security practice.

One local option is OWASP Juice Shop in Docker. If Docker is already installed, bind the container only to the loopback address:

docker pull bkimminich/juice-shop
docker run --rm --name juice-shop \
  -p 127.0.0.1:3000:3000 \
  bkimminich/juice-shop

Open the application at:

http://127.0.0.1:3000

The loopback binding prevents other hosts on the network from directly reaching the container through that published port. Stop it with Ctrl+C if it is running in the foreground.

Use the following lab rules:

1. Test only the local training application.
2. Do not reuse real passwords or personal information.
3. Create test accounts with clearly labelled data.
4. Avoid denial-of-service tests and uncontrolled automation.
5. Record the exact request, expected result and actual result.
6. Reset the application if a test changes its state unexpectedly.

Burp includes an embedded Chromium browser that is preconfigured to use its proxy. Open it from Proxy > Intercept > Open browser. This is usually the simplest setup for a beginner.

For an external browser, configure the HTTP and HTTPS proxy as:

Proxy host: 127.0.0.1
Proxy port: 8080

To inspect HTTPS traffic, visit http://burp through the configured browser, download the Burp CA certificate and trust it for websites. Install this certificate only in a dedicated testing browser profile, and remove it when the lab is no longer required.

How do you intercept and understand an HTTP request?

Turn interception on, perform one simple action in the lab and identify the request caused by that action. Read the method, path, headers, cookies and body before changing anything.

For example, submitting a synthetic profile form could produce this request:

POST /api/profile HTTP/1.1
Host: 127.0.0.1:3000
Content-Type: application/json
Cookie: session=LAB_SESSION_VALUE
Accept: application/json

{"displayName":"NR Student","city":"Chennai"}

Each section has a purpose:

Start with observation. Forward the original request and note the response status, body length and visible result. A baseline is necessary because a changed response does not automatically prove a vulnerability.

Next, use a harmless marker such as NRTEST-2026 in one field:

{"displayName":"NRTEST-2026","city":"Chennai"}

Forward the request and check where that value appears. It might be returned in JSON, inserted into HTML, stored for later display or rejected by server-side validation. The context determines which security control is required.

Use Proxy > HTTP history to locate the request again. Apply filters for the lab host, methods such as POST, or responses containing particular status codes. Add the lab host to the target scope so unrelated browser traffic does not distract you.

How do you use Burp Repeater?

Repeater lets you resend one request many times while changing a single element. It is useful for controlled comparisons because the browser does not need to repeat the full workflow for every variation.

Right-click a request in HTTP history and choose Send to Repeater, or use Ctrl+R on supported desktop platforms. Open the Repeater tab and select Send.

Use this sequence:

1. Send the unmodified request.
2. Record its status code, response length and important body fields.
3. Change one parameter, header or cookie.
4. Send the modified request.
5. Compare the new response with the baseline.
6. Restore the request before testing another variable.

Consider this synthetic lab request:

GET /api/lab/orders/1001 HTTP/1.1
Host: 127.0.0.1:3000
Cookie: session=ALICE_LAB_SESSION
Accept: application/json

The authorised test account owns order 1001. In a deliberately vulnerable lab with seeded records, change the identifier to a record assigned to a second test account:

GET /api/lab/orders/1002 HTTP/1.1
Host: 127.0.0.1:3000
Cookie: session=ALICE_LAB_SESSION
Accept: application/json

A secure application should deny access if Alice does not own order 1002 and has no administrative role. A 403 Forbidden response is common, although some applications return 404 Not Found to avoid revealing that the resource exists.

If the second record is returned, do not continue browsing other identifiers. Save the minimum evidence required, describe the expected access-control decision and stop the test. This follows the validation and reporting stages described in the ethical hacking phases from reconnaissance to reporting.

Which web flaws can beginners investigate safely?

Beginners can check input handling, authentication boundaries, authorisation decisions, session behaviour and security headers in a controlled lab. The objective is to gather evidence with minimal requests, not to damage data or extract unnecessary information.

Reflected or stored input

Submit a unique marker such as:

NRTEST-2026

Find it in the response and identify its context:

• Plain text in HTML
• An HTML attribute
• JSON data
• A URL
• A JavaScript string

You can then try a harmless formatting string in the isolated lab:

<b>NRTEST-2026</b>

If the browser renders bold text rather than displaying the tags, the application may be inserting input as HTML. This is not by itself a complete cross-site scripting finding. Confirm the output context, encoding behaviour and applicable browser protections without using a harmful payload.

Access-control weaknesses

Use two accounts that you created for the lab. Account A must not be able to read, edit or delete Account B's records unless the application explicitly permits it.

Test one valid identifier belonging to each account and compare:

A requests A's record -> expected success
A requests B's record -> expected denial
B requests B's record -> expected success

Check object identifiers in paths, query strings and JSON bodies. Server-side authorisation must be enforced for every request; hiding a button in the browser is not sufficient.

Input validation problems

Change one value at a time to test length, type and required-field validation. Safe examples include:

Expected number: abc
Expected positive value: -1
Expected short name: a long but controlled test string
Required field: empty value

A rejected value may produce 400 Bad Request or a structured validation message. A 500 Internal Server Error suggests unhandled input, but it does not reveal the root cause by itself.

In a local training lab, a single quote can also be used as a minimal error-handling check:

NRTEST'

Do not proceed to data extraction. Record whether the server exposes database errors, returns a generic response or handles the value normally.

Session and authentication checks

Send the baseline request, remove the session cookie and send it again. A protected endpoint should normally return an authentication error or redirect to sign-in rather than disclose private data.

Also check what happens after a controlled logout. If the old session still works, repeat once to rule out browser caching and document the result. Avoid testing session tokens belonging to real users.

Security headers

Review response headers such as:

Content-Security-Policy: default-src 'self'
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=31536000
Set-Cookie: session=VALUE; Secure; HttpOnly; SameSite=Lax

A missing header is usually a hardening observation rather than proof of direct exploitation. Interpret it according to the application's use of HTTPS, cookies, scripts and embedded content.

How should you validate and report a possible flaw?

A good finding must be reproducible, limited in scope and supported by clear evidence. Explain the security boundary that failed instead of reporting every unusual status code as a vulnerability.

Use this evidence structure:

Remove passwords, full session tokens and unnecessary personal data from screenshots or reports. For broader defensive skills, including alert review and incident workflows, see the Cybersecurity and SOC course.

Why is Burp Suite not capturing traffic?

Most capture problems come from incorrect proxy settings, interception being left on, certificate trust errors or requests going to the wrong interface. Check the browser, Burp listener and target address in a fixed order.

The browser keeps loading

Open Proxy > Intercept and check whether a request is waiting. Select Forward, or turn interception off while navigating normally.

No requests appear in HTTP history

Confirm that:

• Burp is running.
• A proxy listener is active on 127.0.0.1:8080.
• The browser uses the same address and port.
• Browser proxy bypass settings do not exclude the target.
• The correct Burp project window is open.

Try Burp's embedded browser to separate browser configuration problems from Burp listener problems.

HTTPS pages show certificate errors

Install the Burp CA only in the dedicated testing browser profile. Verify that the browser imported it as a trusted authority for websites, then restart the browser if required.

Do not disable certificate validation globally. Some applications use certificate pinning, which requires a different authorised testing approach and may not work with a standard proxy configuration.

The local application is unreachable

Check the running container:

docker ps
docker logs juice-shop
curl -I http://127.0.0.1:3000

A successful curl response proves that the application is listening locally, even if the exact HTTP status varies by route. If Docker shows no container, start the lab again and review any port-conflict message.

Repeater sends malformed requests

Start again from a known working request in HTTP history. Check the method, path, Host, Content-Type, cookie and body syntax. Burp normally handles message length updates, but invalid JSON, a missing boundary or an expired session can still cause rejection.

What is a practical Burp Suite beginner workflow?

A reliable workflow is scope, observe, baseline, change one variable, compare and report. This keeps tests understandable and reduces the chance of unintended effects.

1. Confirm written authorisation and scope
2. Start an isolated lab
3. Configure the Burp proxy
4. Browse with interception off
5. Review HTTP history
6. Capture one important request
7. Send it to Repeater
8. Establish a baseline response
9. Change one input or access condition
10. Compare and document the result
11. Stop after minimum confirmation
12. Reset the lab if necessary

Summary

Burp Suite Proxy shows how browsers communicate with web applications, while Repeater makes controlled request comparison possible. Safe testing depends on written permission, a defined scope, isolated practice targets and minimal evidence collection.

Focus first on understanding HTTP requests and responses. Once that foundation is clear, input handling, session controls and authorisation flaws become easier to identify and explain accurately.

To practise these skills through guided labs, request syllabus and batch details for the Ethical Hacking course.

Reviewed by Network Rhinos cybersecurity trainers.