Burp Suite Proxy Tutorial: Intercept in 7 Easy Steps

Burp Suite Proxy is an intercepting web proxy that sits between your browser and a web application, letting you pause, inspect, modify, and forward HTTP requests before they reach the server. For beginners, intercepting one normal request is the best way to understand what Burp actually does without immediately disappearing into a forest of tabs, scanners, and buttons.

This Burp Suite Proxy tutorial focuses on exactly that skill. You will configure the proxy, launch a testing browser, intercept one request, understand its important parts, make one harmless modification, forward it, and verify what happened. Nothing more ambitious is required for your first session.

The idea behind Burp Suite Proxy Tutorial: 7 Easy Steps That Work is deliberately practical. I learned much more once I stopped trying to “use Burp Suite” as one giant activity and instead gave myself a tiny objective: capture one request and explain everything I can see inside it. That turns Burp from a slightly intimidating dashboard into something much more useful: a window into how a browser actually talks to a web application.

If you enjoy practical cybersecurity labs, web security experiments, and lessons learned from actually pressing the buttons instead of admiring them from a screenshot, you can also join my HackersGhost newsletter. I share the lab notes and observations that survive contact with real software.

Everything in this guide assumes that you are testing your own application, a deliberately vulnerable lab, or another system for which you have explicit authorization. Burp is excellent at showing you what a browser sends. It is less talented at checking whether you remembered to get permission first.

Burp Proxy task	What you learn	Beginner goal
Intercept	What the browser actually sends	Capture one clean request
Inspect	Methods, paths, headers, cookies and parameters	Understand the request
Modify and forward	How one controlled change affects behavior	See cause and effect

Key Takeaways

• Burp Suite Proxy works between your browser and the target application. It can hold a request before the server receives it.
• The easiest Burp Suite Proxy setup for a beginner is Burp’s built-in browser because it is already configured to use the proxy.
• You do not need to modify anything dangerous. Changing a harmless search term, language value, or lab parameter is enough to understand interception.
• HTTP method, path, headers, cookies, query parameters, and request body are more important than memorizing where every Burp button lives.
• The default local Proxy listener is normally 127.0.0.1:8080, but you should verify the listener instead of treating a tutorial screenshot as sacred scripture.
• An external browser needs its own Burp Suite Proxy settings, and HTTPS interception also requires the browser to trust Burp’s CA certificate.
• This tutorial intentionally stops before deeper Burp testing. Once you can reliably intercept and understand a clean request, tools such as Repeater become much easier to learn.

What Is Burp Suite Proxy and Why Intercept One Request?

Burp Suite Proxy is a local web proxy. Instead of your browser communicating directly with the web application, the traffic passes through Burp first. Burp can record that traffic in HTTP history or, when interception is enabled, pause a message and let you inspect it before deciding what happens next.

That is the core idea behind this Burp Suite Proxy tutorial. I am not scanning an application, brute-forcing anything, or launching automated attacks. I am simply placing myself in the middle of a browser conversation that I am authorized to observe.

A browser normally hides most of this conversation. I click a button and a page changes. Burp exposes the machinery underneath: perhaps a GET request for a product page, a POST request containing form data, a session cookie identifying my logged-in lab account, or an API request carrying JSON.

The official PortSwigger documentation is where I check Burp behavior and features when I want the authoritative reference. For broader web security methodology, I also use the OWASP project. Both are worth bookmarking before your collection of random security bookmarks develops its own weather system.

HackersGhost Note: The first useful question I ask in Burp is not “What can I attack?” It is “What did my browser just send?” If I cannot explain the normal request, modifying it is mostly educated button pressing.

My Safe Lab for This Burp Suite Proxy Tutorial

I prefer learning how to use Burp Suite Proxy inside a lab I can break, reset, and inspect without involving unrelated systems. My main machine is a second-hand HP EliteBook that I upgraded from 16 GB to 32 GB of RAM. I use VMware for virtualization and keep both Kali Linux and Parrot OS available, although Parrot OS is where I spend most of my ethical hacking lab time.

For a Burp exercise, I can run Burp inside Parrot OS and point its browser at a deliberately vulnerable web application in another VM. This creates a simple relationship: browser, Burp Proxy, vulnerable application. That is enough. I do not need six network interfaces and a diagram that resembles railway planning.

I also maintain separate physical networking equipment for other experiments. My Cudy WR3000 handles privacy-focused outbound traffic through ProtonVPN WireGuard with Secure Core, while my TP-Link Archer C6 can be isolated and used for controlled network testing rather than normal household traffic. For this Burp Suite Proxy tutorial, however, VM isolation matters more than the VPN. A VPN changes routing and privacy properties; it does not magically turn an unauthorized web test into an authorized one.

When following these seven steps, use a deliberately vulnerable application, a test installation of your own site, or another explicitly approved target. Burp Proxy can work against production applications, but beginners benefit from an environment where mistakes have boring consequences.

HackersGhost Note: I like labs where the worst possible outcome is “restore snapshot.” That leaves me free to experiment instead of wondering whether I just gave the family router an unexpected career change.

How to Use Burp Suite Without 7 Common Beginner Mistakes

How to Use Burp Suite Without 7 Common Beginner Mistakes

Step 1: Define a Safe Target Before Your Burp Suite Proxy Setup

Before touching the Burp Suite Proxy settings, decide exactly what you are going to open. For a beginner exercise, one application is enough. I prefer a deliberately vulnerable web app or a disposable test version of something I own.

Your objective in this Burp Suite Proxy tutorial is intentionally narrow:

1. Open one authorized application.
2. Perform one harmless browser action.
3. Intercept the resulting request.
4. Understand what each important field means.
5. Modify one non-sensitive value.
6. Forward the request.
7. Observe the result.

That small scope is useful because modern pages generate a surprising amount of background traffic. Analytics requests, scripts, fonts, APIs, images and browser services can all appear while you are trying to find the one request you actually care about.

For your first run, choose something obvious such as opening a page containing a query parameter or submitting a harmless search form. You want a request that is easy to recognize when Burp catches it.

Step 2: Check the Burp Suite Proxy Listener

The next part of the Burp Suite Proxy setup is checking that Burp has somewhere to receive browser traffic. A Proxy listener is the local service that accepts those connections.

Burp normally creates a listener on:

127.0.0.1:8080

127.0.0.1 is the loopback address, which means the listener is available locally on that system. Port 8080 is Burp’s usual default listener port.

If you want to verify the current Burp Suite Proxy settings, open Burp’s settings and locate the Proxy listener configuration. Confirm that a listener is running. If another application already occupies port 8080, Burp may not be able to bind to it, in which case another available local port can be configured.

This check matters more when you use an external browser. With Burp’s built-in browser, much of the configuration is handled automatically. Still, knowing what a listener is will save you from staring suspiciously at Firefox, Chrome, your firewall, DNS, the moon phase, and everything except the actual port conflict.

HackersGhost Note: When Burp receives no traffic at all, I check the path logically: Is Burp running? Is the listener running? Is the browser actually using that listener? Debugging the chain in order is much faster than changing five unrelated settings at once.

Step 3: Open Burp’s Browser for the Easiest Proxy Setup

For a first Burp Suite Proxy tutorial, I recommend Burp’s own browser. Go to Proxy → Intercept and choose Open Browser.

The major beginner advantage is simple: Burp’s browser is already configured to communicate through Burp Proxy. You do not need to begin your first lesson by manually changing operating-system proxy settings or importing certificates.

That keeps the mental model clean:

Burp browser
      |
      v
Burp Suite Proxy
      |
      v
Authorized lab application

Open your safe target in this browser with interception temporarily off. Then look in Proxy → HTTP history. You should see requests appearing as you browse.

This little check answers an important question before you start intercepting anything: is traffic actually passing through Burp?

If HTTP history is filling with requests, your basic Burp Suite Proxy setup works. You are now ready to stop one message deliberately instead of wondering whether Burp and the browser have even met.

Step 4: Intercept Your First Web Request

This is the central step in the Burp Suite Proxy tutorial. In Proxy → Intercept, switch interception on. Burp should indicate that interception is enabled.

Now return to Burp’s browser and perform one simple action. For example, load a page in your lab or submit a harmless search.

The browser may appear to pause. That is expected. The request has not necessarily reached the application yet because Burp Suite Proxy is holding it in the Intercept tab.

You may see something structurally similar to this:

GET /search?q=burp HTTP/1.1
Host: lab.example
User-Agent: Mozilla/5.0
Accept: text/html
Cookie: session=example-value

The exact headers will vary, and a modern browser often sends many more. Do not worry about understanding every line immediately. Your first task is to recognize that this is the HTTP request your browser wanted to send.

At this point I usually do nothing for a moment. I read it. Burp makes editing easy, but the ability to edit a request is less useful than understanding what I am editing.

HackersGhost Note: The first intercepted request was the point where HTTP became much less abstract for me. Headers stopped being definitions in an article and became things my own browser was producing right in front of me.

Step 5: Inspect the Request Before You Change Anything

Good Burp Suite Proxy tutorial exercises should spend more time here than on clever modifications. A request contains clues about how the application expects the browser to behave.

HTTP Method

The first word is commonly something such as GET or POST. A GET request normally retrieves a resource, while POST is commonly used when data is being submitted. Other methods exist, but you do not need a complete HTTP archaeology course before your first interception.

Path and Query String

In this example:

/search?q=burp

/search is the path and q=burp is a query parameter. Parameters are particularly useful for learning because changing a harmless value can produce an immediate visible difference.

Host Header

The Host header tells the server which hostname the browser wants. One IP address can host several web applications, so this field matters more than beginners sometimes expect.

Cookies

Cookies can carry session identifiers, preferences, state information and other values. Treat session cookies as sensitive data. A Burp project containing authenticated traffic can hold information you would not casually publish in a screenshot.

Request Body

A POST request may contain form fields, JSON or another body format. If you intercepted a form submission, the values you typed into the page may suddenly be sitting there in remarkably ordinary text.

That observation is one reason a Burp Suite Proxy tutorial is useful even before vulnerability testing. You start seeing web applications as requests and state transitions rather than only pages.

Step 6: Modify One Harmless Value in Burp Suite Proxy

Now make one controlled edit. The emphasis is on one.

Suppose your lab search generated:

GET /search?q=burp HTTP/1.1

You could change it to:

GET /search?q=proxy HTTP/1.1

That is enough for this Burp Suite Proxy tutorial. You have changed something the browser originally generated without attempting to exploit the application.

Other safe lab examples include changing a language preference, page number, sort order, harmless display option, or another input whose behavior you already understand.

I avoid changing several fields together when learning. If I modify a query parameter, a cookie and three headers and the response changes, I have learned only that something mattered. That is not exactly the scientific method’s finest afternoon.

Changing one value gives you a clean comparison:

• Original request: known normal behavior.
• Modified request: one intentional difference.
• Response: evidence of what that difference changed.

HackersGhost Note: One-variable testing sounds almost too simple, but it makes my Burp sessions much easier to explain later. If the response changes, I know exactly what I touched.

Step 7: Forward the Request and Verify the Result

Once you have inspected and optionally modified the request, click Forward. Burp releases the message and allows it to continue toward the application.

Return to the browser and observe the result. If you changed a harmless search value from burp to proxy, the application may now display results for the modified term even though that is not what you originally typed into the browser.

That simple moment demonstrates the entire purpose of this Burp Suite Proxy tutorial:

Browser created request
        ↓
Burp intercepted it
        ↓
I inspected it
        ↓
I changed one value
        ↓
Burp forwarded it
        ↓
Application processed the modified request

Afterward, switch interception off and look in Proxy → HTTP history. History is extremely useful because you can browse normally while Burp records the requests without stopping every single one.

For me, learning the difference between interception and history was important. I do not leave Intercept on simply because I am using Burp. I turn it on when I want to hold a particular message. For normal observation, HTTP history is much less disruptive.

Nikto Web Server Scanner: 7 Useful Checks for Beginners

Nikto Web Server Scanner: 7 Useful Checks for Beginners

How to Configure Burp Suite Proxy With Any Browser

Once the built-in browser makes sense, you may want to learn how to configure Burp Suite Proxy with any browser. I treat this as a second exercise, not a prerequisite for the first one.

The general idea is to configure a dedicated testing browser or testing profile to use Burp’s listener as its HTTP and HTTPS proxy. If your listener is still using the default local configuration, that normally means:

Proxy host: 127.0.0.1
Proxy port: 8080

Exact menus vary between browsers and operating systems. Some browsers use their own network configuration while others rely more heavily on the operating system’s proxy settings.

For HTTPS interception, an external browser must also trust Burp’s locally generated CA certificate. Do that only in a dedicated testing browser or profile. I do not like mixing a web-testing trust configuration with my normal everyday browser.

A separate profile also reduces irrelevant traffic, saved accounts, extensions and personal sessions appearing in your Burp project. Clean testing data is much easier to reason about.

Burp Suite Proxy Setup Chrome: Keep It Separate

If you specifically searched for Burp Suite Proxy setup Chrome, the principle is the same: Chrome traffic must be directed toward the active Burp listener, and Burp’s CA certificate must be trusted by the relevant testing environment when you want to inspect HTTPS.

I would create a dedicated Chrome testing profile or use Burp’s preconfigured browser rather than reworking my normal browser. Your everyday sessions, password manager, social accounts and random background tabs have no useful role in a beginner interception exercise.

That separation is one of those tiny habits that makes how to use Burp Suite Proxy much cleaner in practice.

Burp Suite Proxy Settings I Actually Check

Burp contains many Proxy settings, but beginners do not need to adjust everything. For this Burp Suite Proxy tutorial, I care about a small set of things:

• Proxy listener: Is the listener running on the address and port I expect?
• Intercept state: Do I currently want requests held or merely recorded?
• HTTP history: Can I see the target requests arriving?
• Scope and filtering: Am I looking at the application I actually intend to test?
• External browser certificate: If I chose an external browser, is HTTPS configured correctly?

You can explore advanced interception rules, response modification, match-and-replace behavior, TLS pass-through and other features later. They solve real problems, but none is required to understand your first web request.

I prefer learning a setting when I have a reason to change it. Randomly customizing Burp before understanding the defaults is a surprisingly effective way to create a unique technical problem for which no tutorial screenshot matches.

Why Is My Burp Suite Proxy Not Working?

If your Burp Suite Proxy setup does not work, troubleshoot the path in order instead of changing everything at once.

Nothing Appears in HTTP History

First confirm that Burp is running and that the Proxy listener is active. If you use an external browser, confirm that the browser is actually configured to send traffic to the correct listener.

The Browser Suddenly Stops Loading

Check whether Intercept is on. The browser may be waiting because Burp has deliberately paused the request. Look at the Intercept tab and either forward or drop the message.

HTTP Works but HTTPS Fails in an External Browser

This often points toward certificate configuration. External browsers need to trust the Burp CA certificate before Burp can transparently inspect HTTPS traffic. Burp’s own browser avoids much of this setup because it is already configured for the Burp workflow.

Port 8080 Is Already in Use

Another application may already be listening there. Configure Burp to use another available port, then make sure the browser configuration matches it. A proxy configured for port 8080 will not develop telepathy because Burp moved to 8081.

There Is Far Too Much Traffic

Use a clean testing browser, close unrelated tabs, define your authorized target clearly, and use filters. Modern websites can produce dozens of requests for one visible action. Your job is not to inspect every pixel personally.

HackersGhost Note: My favorite Burp troubleshooting technique is still the boring one: prove each link in the chain. Listener, browser, request, history, target. Boring troubleshooting has an irritating habit of working.

Where My VPN Fits Into a Burp Lab

I use ProtonVPN extensively for privacy-oriented internet traffic, including WireGuard through my Cudy router and Secure Core when I want that routing model. It is part of my wider lab and privacy setup, but I keep its role separate from Burp.

A VPN is not required for this Burp Suite Proxy tutorial. Burp is intercepting browser-to-application traffic because I intentionally configured that path. VMware networking and segmentation keep vulnerable systems where I want them. The VPN deals with selected outbound traffic and privacy.

If you already use ProtonVPN and also want encrypted email, cloud storage and a password manager, I personally find the combined Proton package more convenient than maintaining those services independently.

Proton Unlimited combines ProtonVPN, Proton Mail, Proton Drive, and Proton Pass under one subscription. If several Proton services already fit your privacy or lab workflow, the bundle can be the simpler option.

A Burp Suite Book for Going Beyond the First Request

Once you understand interception, a focused reference can help connect Proxy with the rest of a web testing workflow. Burp Suite Hacking: From Recon to Exploitation is directly relevant if you want reading material centered on Burp rather than a general security book.

I would still build the lab before trying to absorb every Burp technique from a book. Intercepting a real request yourself gives the terminology somewhere to live. “Proxy listener” becomes much easier to remember once you have spent five minutes wondering why yours was not running.

Gobuster Tutorial for Beginners: Find Hidden Directories Safely

Gobuster Tutorial for Beginners: Find Hidden Directories Safely

What to Learn After This Burp Suite Proxy Tutorial

Once you can consistently intercept, inspect, modify and forward one request, stop repeating the beginner exercise and move to the next skill.

This is also where I deliberately separate this article from my broader guide, How to Use Burp Suite Without 7 Common Beginner Mistakes. That article deals with the wider workflow: scope, baselines, Repeater, application state, documentation and the habits that keep a Burp session understandable.

This page has a narrower job. If you searched for a Burp Suite Proxy tutorial, you should finish it knowing exactly what happens between clicking a link in the browser and the server receiving the request.

Your logical next exercises are:

• Compare several requests in HTTP history.
• Learn which cookies and parameters carry application state.
• Send one interesting request to Repeater for controlled manual testing.
• Compare a normal request with one deliberately changed request.
• Practice against purpose-built vulnerable labs rather than random internet targets.

I would not rush into automation yet. Understanding five normal requests is more valuable than generating five thousand requests you cannot explain.

HackersGhost Note: Burp became much more enjoyable for me once every tool had a job. Proxy shows me the conversation. Repeater becomes useful when I want to study one part of that conversation repeatedly. Keeping those jobs separate also keeps my notes considerably less haunted.

Is Burp Suite Proxy Worth Learning for Beginners?

Absolutely. I think Burp Suite Proxy is one of the most useful places to start learning web security because it exposes concepts that apply far beyond Burp itself.

You begin recognizing HTTP methods, headers, cookies, parameters, request bodies, redirects and application state as real pieces of traffic rather than vocabulary from a certification chapter. You also learn that the browser interface is only one interpretation of what the application is doing.

The best part of this Burp Suite Proxy tutorial is that the first meaningful experiment is tiny. You do not need a powerful exploit, a complicated payload or an expensive testing environment. You need one controlled web application and the curiosity to ask what your browser sent.

That skill scales surprisingly well. Later, when you encounter authentication logic, API calls, access controls or interesting parameters, you already understand how to capture the request and look at the evidence directly.

Final Thoughts: Intercept First, Complicate Things Later

This Burp Suite Proxy tutorial has one intentionally modest goal: get your first web request from the browser into Burp, understand what you are looking at, make one safe modification, and forward it.

The seven steps are straightforward: define an authorized target, verify the Proxy listener, open Burp’s browser, enable interception, inspect the request, modify one harmless value, and forward it. If you can repeat that sequence without guessing, you already understand the most important concept behind Burp Proxy.

I would rather see a beginner confidently explain one captured request than rapidly click through ten Burp tools. The interface will still be there tomorrow. HTTP fundamentals are the part worth keeping.

And once your first intercepted request makes sense, move onward. Use HTTP history. Compare behavior. Learn Repeater. Build increasingly realistic lab exercises. Burp becomes powerful because those pieces connect, not because every button needs attention during your first hour.

Frequently Asked Questions