Security
Burp Suite
The proxy most manual security testing happens in.
Burp Suite in practice
A desktop toolkit for examining web applications by hand, built around an intercepting proxy that lets a tester see, alter and replay every request a browser makes. The parts that matter are the ones a person drives: replaying one request with a single parameter changed, iterating a payload across an input, and comparing responses closely enough to notice the one that came back different. An extension ecosystem covers frameworks and protocols the core product does not handle natively.
This is where the manual half of an OWASP-aligned assessment actually happens. Authorisation testing in particular lives here, because proving one account cannot reach another account’s data means capturing a request as one user, replaying it as a second, and reading what comes back with real attention. The same applies to input handling, session management, and anything where the question is what an application does with a value it never expected to receive. A scanner suggests where to look; this is what we look with.
The tier worth having is paid, per user, per year. The free edition is a genuinely usable proxy and deliberately constrained everywhere else, so licensing belongs in the decision rather than in a detail to resolve later.
It rewards the operator rather than the purchaser. In unpractised hands it is an expensive proxy, and what comes out of an engagement tracks the tester far more closely than it tracks the licence.
The desktop product is not a continuous integration tool. Scanning on every build is a different product in the same range at a different price, and assuming otherwise produces an awkward conversation partway through a project.
It is a Java desktop application with a healthy appetite for memory once a project history grows, which becomes a practical problem when the assessment runs on a client-provided laptop.
Nothing about it makes intrusive work safe by default. Replaying a modified request against the wrong environment is exactly as consequential as that sounds, and the tool will not stop you.
FAQ
Burp Suite questions we hear often
Do we need to buy a licence for you to test our application?
No. Tooling is ours to supply and its cost sits inside the engagement rather than arriving as something for you to procure separately. Where it does become your decision is if your own engineers should be doing this work between assessments, in which case both the seat cost and the time to become effective with it are real and worth planning around.
Can the scanner run on our build pipeline?
Not this edition. Continuous scanning is a separate product in the same range with its own licensing model, and where pipeline coverage is the goal we would normally put a free scanner there and keep the paid toolkit for manual work. Two tools doing the jobs they were designed for costs less than one tool used against its design.
What does manual testing find that a scanner misses?
Anything depending on knowing what the application was supposed to do. Broken access control, flawed business logic, sequences that are each individually permitted and collectively harmful, and chains where a minor issue becomes serious in combination with a second one. Automated tooling has never handled those well, and they are the reason a real assessment involves a person.
Does using it make this a penetration test?
No, and we hold to that distinction rather than blurring it. A penetration test in the formal sense carries an accredited methodology and a certified tester behind the signature. What we run is a structured assessment against OWASP guidance using the same tooling, producing demonstrated findings with reproduction steps. Where an obligation names a certification, you need a firm holding it.
Contact
Wondering if this is the right tool?
Describe what you are trying to verify and we will tell you which instrument fits, including when the answer is one we do not use.