Burp Suite Proxy Basics

The Interception Problem

When you test a web application, you need to see and modify every request your browser sends. Without a proxy, requests go directly from browser to server — you can observe them in browser dev tools, but you cannot pause them, edit them mid-flight, or replay them. Burp Proxy solves this by sitting between the two.

How the Proxy Chain Works

Your browser sends a request to Burp Proxy (default 127.0.0.1:8080). Burp holds the request, displays it, and lets you edit it. When you click Forward, Burp sends the modified request to the server. The server responds back to Burp, which again holds and displays it before passing it to your browser.

Browser <---> Burp Proxy (127.0.0.1:8080) <---> Target Server

This means every single request and response passes through your hands. You can:

• Intercept — pause requests before they reach the server
• Modify — change parameters, headers, cookies, or body content
• Drop — discard requests you do not want to send
• Forward — release the request to the server

Configuring Your Browser

In Burp, go to Proxy > Options and confirm the proxy listener is running on 127.0.0.1:8080. Then configure your browser to use this proxy. In Firefox: Settings > Network Settings > Manual proxy configuration > HTTP Proxy 127.0.0.1, Port 8080. Check "Also use this proxy for HTTPS."

Firefox is preferred over Chrome for Burp testing because it uses its own proxy settings rather than the system-wide settings, keeping your non-test traffic separate.

The Intercept Toggle

The Intercept button in the Proxy tab is your pause switch. When it reads "Intercept is on," every request waits for your action. When it reads "Intercept is off," Burp passes traffic through without stopping. You toggle this depending on whether you want to review each request or let the browser flow freely while Burp logs everything in the HTTP history.

Why This Matters

Without proxy interception, you are testing blind. You see what the page renders but not the underlying API calls, parameter values, or headers that actually drive the application. The proxy is the foundation — every other Burp tool (Repeater, Intruder, Scanner) depends on traffic flowing through it first.

The Certificate Problem

Once your browser routes through Burp, HTTP sites work immediately. But HTTPS sites throw a certificate warning. This happens because Burp acts as a man-in-the-middle: it terminates your HTTPS connection, inspects the traffic, then opens its own HTTPS connection to the server. Your browser sees Burp's certificate, not the server's, and correctly warns you that something is different.

Installing Burp's CA Certificate

Burp generates its own Certificate Authority (CA) during installation. You need to tell your browser to trust this CA so it accepts Burp's dynamically generated certificates for any site.

Step 1: With the proxy running, visit http://burpsuite in your proxied browser. Click "CA Certificate" to download cacert.der.

Step 2 (Firefox): Settings > Privacy & Security > Certificates > View Certificates > Authorities > Import. Select the downloaded file. Check "Trust this CA to identify websites."

Step 3 (System-wide, for non-browser tools): Import the certificate into your operating system's trust store. On Windows: certmgr.msc > Trusted Root Certification Authorities > Import.

Verifying HTTPS Interception Works

After importing the certificate, visit https://example.com through the proxy. If the padlock appears without warnings and you see the request in Burp's Proxy > HTTP history tab, interception is working. If you still get warnings, the certificate import did not succeed — re-import and restart the browser.

What Burp Sees vs. What the Server Sees

When HTTPS interception is active, Burp decrypts traffic, displays it in plain text, then re-encrypts it before sending to the server. This means you can inspect and modify encrypted traffic just like HTTP. The server has no idea Burp is in the middle — from its perspective, Burp's connection is just another client.

Certificate Pinning — When Interception Fails

Some applications use certificate pinning: they hardcode the expected server certificate or public key and reject any other certificate, including Burp's. When pinning is active, you will see SSL errors even with Burp's CA installed. Workarounds include:

• Using a mobile device with a modified app (for mobile apps)
• Using Frida to hook and disable pinning checks at runtime
• Testing against a staging environment where pinning is disabled

For standard web applications, pinning is rare — most browser-based apps rely on the system trust store, which you control.

Why Scope Matters

Without scope, Burp logs every request your browser makes — Google analytics, CDN assets, social media widgets, your email. This noise buries the traffic you actually care about. Scope tells Burp: "Only care about requests to these domains and paths."

Setting Scope in Burp

Go to Target > Scope. Click "Add" under "Include in scope" and enter your target. For example:

Protocol:    https
Host:        target.example.com
Port:        (leave blank for any)
File:        (leave blank for all paths)

You can also right-click any request in the proxy history and select "Add to scope" to quickly define scope from observed traffic.

Using Scope to Filter

Once scope is set, use the filter bar above the HTTP history to show only in-scope items. In the Target tab, the site map will only display scoped content. This keeps your testing focused and your reports clean.

Practical Workflow

A typical Burp Proxy workflow follows this sequence:

1. Configure — Set browser proxy, install CA certificate, verify HTTPS works
2. Define scope — Add target domains to Target > Scope
3. Browse — Turn Intercept off, navigate the application normally, let Burp build the site map
4. Identify — Review the site map for interesting endpoints, parameters, and forms
5. Intercept — Turn Intercept on for specific requests you want to modify
6. Send to Repeater — Right-click any request and send it to Repeater for detailed manipulation

Common Mistakes

• Forgetting to install the CA certificate — Every HTTPS request fails with SSL errors
• Setting scope too broadly — Including *.example.com catches unrelated subdomains
• Leaving Intercept on during normal browsing — Every page load stalls waiting for you to click Forward
• Not checking the HTTP history — Requests you did not intercept are still logged; review them for API calls and hidden endpoints

Scope and Reporting

When you generate a report (Target > Site map > right-click > Save selected items), Burp includes only in-scope findings by default. This ensures your penetration test report covers the agreed targets and does not include noise from third-party services.