Why I'm learning Burp Suite (and you should too)

When you're learning web development, the debugger is the tool that changes everything. The first time you set a breakpoint, step through a function, and watch a variable hold a value you didn't expect, you stop guessing. You start seeing what the code actually does instead of what you assumed it did.

A web proxy is that same moment, but for the network. It is to a web pentester what a debugger is to a developer. That is the whole reason I'm learning Burp Suite right now, and I think anyone building or breaking web apps should at least understand what it is.

I'll be straight up front: I have not passed the eJPT yet. I'm studying for it, and Burp keeps showing up in the web attack material, so I sat down to actually understand it instead of just clicking buttons. These are my study notes, cleaned up.

What an intercepting proxy actually is

When your browser talks to a server, it sends an HTTP request. The server sends a response. Normally all of that happens in a fraction of a second and you never see it. You click a button, a thing happens, and the request that carried it is gone before you can look.

An intercepting proxy sits in the middle of that conversation. Your browser is configured to send its traffic to the proxy first (usually something like 127.0.0.1:8080), the proxy passes it on to the server, and the response comes back the same way. Because the proxy is in the middle, it can show you every single request and response, in full, and let you pause and change them before they continue.

That is the part that clicks once you've used a debugger. A debugger lets you freeze execution and inspect state. A proxy lets you freeze a request and inspect, or rewrite, what's going over the wire. Headers, cookies, form fields, JSON bodies, the URL itself. All of it is just text at that layer, and the proxy hands you that text.

One thing worth saying plainly: the browser only sends readable traffic to the proxy because the proxy presents its own certificate, which you install and trust on your own machine. You are intercepting your own traffic on purpose. This is for testing apps you are allowed to test. Pointing it at someone else's site to mess with their traffic is not a study exercise, it's a crime.

The three Burp pieces a learner meets first

Burp Suite is a big tool with a lot of tabs, and that is honestly intimidating at first. But you can do a surprising amount with just three of them.

Proxy and Intercept

The Proxy tab is the front door. Inside it there's an Intercept toggle. When Intercept is on and you do something in the browser, the request stops at Burp and waits. You can read it, edit any part of it, then forward it on or drop it entirely.

This is the breakpoint. Submit a login form with Intercept on and you'll see the username and password sitting in the request body in plain text. You can change role=user to role=admin right there and forward it, then watch what the server does. Often the answer is "nothing, it rejects you," which is the correct behavior, and that's useful to confirm too.

There's also the HTTP history sub-tab, which logs every request that passed through even when Intercept is off. I leave Intercept off most of the time and just browse the app normally, then go read the history to understand what the app is doing under the hood. It's like leaving a logger running instead of stepping line by line.

Repeater

Repeater is the piece I underestimated. You take any request, send it to Repeater, and now you have a scratchpad. You can fire that exact request again and again, tweaking one thing each time, and read the full response each time.

This is the developer loop applied to a live request. Change a parameter, send, read the response. Change a header, send, read the response. No clicking back through five pages of the app to reach the form again. If a developer's inner loop is "edit, run, observe," Repeater is "edit, send, observe" for a single HTTP request. It is where you actually learn how an endpoint behaves at the edges.

Browser  ->  Burp Proxy  ->  Server
              |
              +-- HTTP history (everything that passed)
              +-- send a request to Repeater (edit + resend by hand)

Intruder, in one sentence

Intruder is the automation step: you mark a position in a request and Burp swaps in a list of values for you, so instead of changing one thing by hand in Repeater a hundred times, it does the hundred for you and shows you the results side by side. That's as far as I've gotten with it, and that's fine for now.

Why this matters even if you only build

If you write web apps and never plan to do security work, watching your own traffic through a proxy is still one of the fastest ways to actually understand your stack. You see exactly what your frontend sends, what cookies ride along, which headers your framework sets, and how your API responds to input you'd never type into the form. A lot of "how does this even work" questions answer themselves once you can see the wire.

The Community edition of Burp is free. Intruder is throttled in it and some of the heavier features are paid, but Proxy, Repeater, and the history are all there, and that is more than enough to learn on.

Where I'm at

I'm still early with this. I can intercept, edit, and resend, and I'm reading responses more carefully than I used to. The eJPT material is what pushed me here, and turning the screenshots in the courseware into things I've actually done myself is slowly working.

If you want the running notes I'm keeping as I study toward the exam, including the proxy stuff, they're in my eJPT Field Notes (aldowebsitellc.xyz/shop/ejpt-field-notes). And if you'd rather just learn this from the builder's side, that's its own thing I'm still figuring out alongside you.