~/tutorials/053-burp-the-same-idea-in-a-different-hand.md

053: Burp, the same idea in a different hand

Two lessons ago you installed a proxy on purpose and drove it from a command line. Everything it did, its history, its passive findings, its scripted spider, one other tool does with the same architecture and a different philosophy. Burp Suite, from PortSwigger, is the tool most professional web testers hold in, and this lesson's job is to take the mystery out of that fact. It is the same idea in a different hand. The proxy is the idea. The hand is what you are choosing.

What this lesson is for

Not a Burp manual. The transfer. If you understand ZAP from the last two lessons, you already understand Burp, and this lesson makes that explicit, part by part, so that the choice between them becomes a choice about workflow rather than a cliff of new learning. And the choice is real, because the hands differ in ways that matter: Burp's manual tools are the industry's smoothest, and its automated ones sit on the far side of a paywall, where ZAP's are all free.

What the reader meets

Burp Suite Community Edition, the free tier, downloaded from portswigger.net or installed from your distribution's package manager. It is a desktop program, first run and every run: a wizard asks which edition, which project, which settings, and then you are in.

The same three shapes you already know, wearing Burp's names. The proxy listener, on loopback 8080 by default, is the same man in the middle you invited in lesson 050, and curl drives it with the same one flag:

$ curl -x http://127.0.0.1:8080 http://127.0.0.1:8422/

The history, which Burp calls HTTP history under the Proxy tab, is the same held conversation. After pushing four requests through the listener, from the lab site's three pages to one external fetch, the history reads, receipted from a real session:

1  http://127.0.0.1:8422  GET /            200  2540  HTML
2  http://127.0.0.1:8422  GET /page2.html  200  1920  HTML
3  http://127.0.0.1:8422  GET /page3.html  200   195  HTML
4  http://example.com     GET /            200   854  HTML  Example Domain

Four conversations, held, numbered, with size and type and title per row. That is lesson 050's promise kept by the other hand.

And the browser, which is where the hands first visibly differ. Burp ships a preconfigured embedded browser, Chromium pre-wired to its own proxy, so the configuration step of lesson 050 disappears: click the button, browse, everything lands in the history. ZAP has the same feature, added later, and the difference is polish, not kind.

The instrument

The transfer table, which is the lesson's core. Read it as: you already know the left column.

ZAP                        Burp                          Same because
daemon, port 8080          proxy listener, port 8080     a proxy is a proxy
JSON API                   no API in Community           ZAP's engine is free-range
history / messages         Proxy -> HTTP history         held conversations
spider                     spider, Pro only              walk the link graph
passive scan               live passive, all editions    read what passes through
active scan                scanner, Pro only             send attack traffic
sendRequest / edit         Repeater                      change one thing, resend

Three rows deserve their weight spoken. The passive scanner runs in every Burp edition, free, and it is the same mechanized reading of responses from lesson 050: browse through the proxy and findings accumulate without any attack fired. Repeater is Burp's name for the power ZAP gave you with sendRequest, and most testers would say its implementation, request and response panes side by side with a send button, is the single best manual tool in the industry. It is free in Community. And the spider and the active scanner, the automation, sit behind the Professional license.

That paywall line is the honest fork in the road, and both roads are walked by professionals. ZAP if you want every capability free, an API, and headless operation in your CI. Burp if your work is primarily manual, if your employer buys the license, or if you are heading toward the jobs whose interviews assume it. The transfer table means you lose nothing either way, because the idea, the proxy, is the same instrument, and your skills in it move across by renaming.

One more difference, the one nobody plans for and everyone meets. Burp's first run is a wizard: edition, project, settings, and in recent versions a license prompt for Community too, a dialog tree walked by clicking. ZAP's daemon starts with one command and no screen. The wizard is not hard, but it is a fact of the hand: Burp wants a human at the glass, at least the first time, and a fully scripted Burp lab is genuinely harder to build than a fully scripted ZAP one. That is not a verdict. It is the difference between a tool built for the tester at the desk and a tool built to live in pipelines, and knowing which you are building is part of choosing the hand.

Try it

Install Burp Community, walk the wizard, and click the embedded browser button. Browse your lab box for two minutes. Then open Proxy, HTTP history, and find your four conversations waiting. No configuration was done, and the instrument from lesson 050 exists anyway. That is the polish you are evaluating.
Run the transfer table against your own hands. For each row, do the thing you already know on the ZAP side, then find its Burp name and do it there. The rows that feel identical are the transfer working. The rows that feel different, Repeater especially, are the new information.
Send one request through Burp's proxy with curl, exactly the line above, then find it in the history. You have now used the two tools through one shared habit, the curl flag from lesson 050, and no tool you ever meet can take that habit away from you.

Reveal the answer

The same-session receipt, both tools, one lab, and what reading it teaches. The lab site was served on a bare port, three tiny pages, index linking two. Through ZAP, lesson 050's receipts: the page fetched, the history count rising, passive alerts accumulating on the login page. Through Burp, this lesson's receipts, same site, same hour:

listener: loopback 8080, up
curl -x http://127.0.0.1:8080 http://127.0.0.1:8422/   -> 200
history: 4 rows, / and page2 and page3 and example.com, all 200

Put the two receipts side by side and read them as one truth wearing two fonts. ZAP's history said: messages, numbered, JSON, queryable by script. Burp's history said: rows, numbered, titled, readable by human. Same held conversations, same passive scanning while they arrived, same loopback listener discipline, same curl flag driving either one. The tools did not disagree about anything. They disagreed about who they were talking to, a script or a person, and that is the entire difference between them, expressed in interface choices and a license line.

The choice that remains, once you see it that way, is not which tool to learn. It is which audience your work has. Scripts and pipelines, lean ZAP, the API is the product. Human-paced manual testing, lean Burp, Repeater and the ecosystem are the product. Test for a living long enough and you will hold both, and the transfer table above is the bridge you will cross each time, usually without noticing, because the proxy underneath is one idea and it is yours.

What this lesson does not claim

Burp Professional's deepest features, Intruder at full speed, Collaborator, the extension marketplace's heavier tools, are named here but not taught, because they live behind a license this site does not assume you hold. And the wizard-walking receipt above came from a headless lab where the wizard was driven by scripted clicks, which is a lab stunt, not a workflow: your first run will be your own mouse and it will be simpler than this paragraph. The lesson claims the transfer, and the transfer is real: one idea, two hands, and the habits you built in the free one are the habits you keep in either.