Burp Suite
The professional standard for web penetration testing. Advanced manual testing, automated scanning, and enterprise reporting.
Overview
Burp Suite, created by PortSwigger in 2003, is the industry-standard tool for web application penetration testing. Used by professional security testers, bug bounty hunters, and enterprise security teams, Burp Suite provides a comprehensive platform for finding and exploiting web vulnerabilities. Its proxy, scanner, intruder, and repeater tools form the core workflow of modern web app security testing.
Burp Suite comes in three editions: Community (free, limited), Professional (paid, full scanner), and Enterprise (paid, CI/CD integration, scheduled scanning). The Professional edition is the de facto standard for penetration testers worldwide.
What it's used for
Burp Suite is essential when:
- Professional penetration testing: The standard tool for security consultants and bug bounty hunters.
- Advanced manual testing: Intercept, modify, and replay requests with precision.
- Automated vulnerability scanning: Burp Scanner finds vulnerabilities with fewer false positives than most tools.
- Enterprise security programmes: Scheduled scanning, reporting, and CI/CD integration with Burp Enterprise.
Pros & Cons
Pros
- The most powerful web proxy for manual testing
- Advanced automated scanner with low false-positive rate
- Massive extension ecosystem (BApp Store)
- Industry standard — expected skill for security professionals
- Enterprise edition with CI/CD integration and reporting
Cons
- Professional edition is expensive (~$449/user/yr)
- Enterprise edition is very expensive
- Steep learning curve for beginners
- Heavy resource usage during large scans
- Community edition is limited (no automated scanner)
Platforms & Integrations
Burp Suite runs on Windows, macOS, and Linux. It requires Java. The Enterprise edition adds cloud-based scanning and CI/CD integration.
Pricing
| Tier | Cost | Includes |
|---|---|---|
| Community | Free | Manual testing, proxy, repeater, limited intruder |
| Professional | $449/user/yr | Automated scanner, advanced tools, extensions |
| Enterprise | Custom | CI/CD integration, scheduled scanning, reporting, unlimited users |
NZ Context
Burp Suite Professional is the certification standard for NZ security testers. The CREST penetration testing certification expects Burp Suite proficiency. NZ cybersecurity consultancies like Insomnia Security and RedShield use Burp Suite daily. For NZ testers interested in security, Burp Suite Professional is a career-critical investment.
Alternatives
- OWASP ZAP — Free alternative with similar proxy capabilities.
- Netsparker (Invicti) — Automated scanner with proof-of-concept exploitation.
- Acunetix — Automated web vulnerability scanner with strong detection rates.
When to choose Burp Suite
A quick decision guide for NZ teams evaluating security testing options.
| Choose Burp Suite when… | Choose something else when… | Combine with… |
|---|---|---|
| You're doing manual penetration testing and need full control over request interception, modification, and replaying. | You need automated scanning at scale across dozens of apps without a tester driving the tool — Acunetix or Invicti (Netsparker) are purpose-built for that workflow. | Nmap for network-layer recon before drilling into the web app; gives you port and service context before you open Burp. |
| Your team is pursuing CREST certification or needs to demonstrate professional security testing capability to a client. | Budget is tight and the scope is light — OWASP ZAP is free, covers common OWASP Top 10 checks, and is perfectly adequate for a development team running their own security smoke tests. | OWASP ZAP in the CI pipeline for passive baseline scanning, with Burp Professional reserved for dedicated pentest sprints — keeps CI costs low and human testing high-value. |
| You're testing APIs — REST, GraphQL, SOAP — and need to manipulate payloads, fuzz parameters, and track session tokens across dozens of chained requests. | You only need functional API testing, not security testing — Postman or Playwright handle contract and load concerns without the overhead of a full proxy setup. | Postman for contract and schema validation, then route authenticated sessions through Burp's proxy to catch auth and injection issues the functional suite misses. |
| You're running a bug bounty programme or participating in one — Burp's Intruder and Collaborator are essential for proving out SSRF, out-of-band injection, and race conditions. | The application is a thick client or mobile app — Burp still helps as a proxy, but you'll also need Frida or apktool for the non-HTTP layers Burp can't see. | Semgrep for static analysis before the pentest — fixing obvious code-level issues first means Burp time goes on logic and business-layer vulnerabilities, not low-hanging SAST findings. |
What I would do
Practitioner judgment on tool adoption, team onboarding, and when to swap.
The bottom line: Burp Suite is a force multiplier for people who already understand HTTP — it surfaces vulnerabilities you can then prove and explain. It is not a push-button scanner you hand to a non-technical stakeholder and trust. Know the difference before you write it into your security testing strategy.
Interview questions
Questions you are likely to get if you list Burp Suite on your CV — with what interviewers are really testing for.
What is the difference between Burp Suite’s passive and active scanning modes, and when would you use each?
What they’re really testing: Whether you understand that active scanning sends attack payloads to the target — something that can break production systems or violate scope rules — versus passive scanning which only analyses traffic already flowing through the proxy.
Strong answer covers: Passive scan is always-on and safe in prod (reads responses, doesn’t send extra requests); active scan fires payloads and must be scoped to a test environment; in a NZ context, active scanning a live government or banking endpoint without written authorisation is a criminal offence under the Crimes Act 1961 s252 — mention that explicitly.
When would you use Burp Repeater instead of Burp Intruder for a finding you want to investigate further?
What they’re really testing: Whether you know that Repeater is for precise, manual one-shot request manipulation while Intruder is for automated fuzzing across a payload list — conflating them signals inexperience.
Strong answer covers: Use Repeater when you have a specific hypothesis to confirm (e.g. tweaking one parameter to prove SQL injection); use Intruder when you need to cycle through a wordlist or brute-force a numeric range; note that Community edition throttles Intruder to make automated attacks painfully slow, so confirm your licence tier before promising speed.
You’re joining CloudBooks’s QA team and security testing has been handed to QA for the first time. The team has no Burp licences and no pentest experience. How would you structure the first 90 days?
What they’re really testing: Whether you can build a security testing capability pragmatically rather than just buying tools and hoping — they want to see risk prioritisation and stakeholder management, not just technical knowledge.
Strong answer covers: Weeks 1–4: one engineer through PortSwigger Web Security Academy with Burp Community (free, legal, structured); weeks 5–8: run a scoped passive proxy intercept on a non-production environment to identify low-hanging OWASP Top 10 issues; only buy Professional licence when that engineer can articulate what the scanner’s active crawl does differently — prevents $449/yr sitting unused in the taskbar.
Your Burp scan flags an IDOR vulnerability in a pre-production API but the same test passes cleanly in CI. How do you diagnose why the environments give different results?
What they’re really testing: Whether you can debug environment inconsistencies methodically and understand that Burp findings are only as reliable as the environment they were captured in.
Strong answer covers: Check whether CI runs a stub/mock vs a real auth service — IDORs often vanish when auth is mocked out; compare the exact request/response in Burp’s HTTP history against what CI is sending (header differences, auth tokens, base URLs); confirm target scope rules in Burp aren’t silently excluding the CI endpoint; document the discrepancy as a configuration risk even if the CI pipeline doesn’t surface it.
How would you structure a repeatable Burp Enterprise scanning programme for a managed services provider running security testing across 20+ client applications simultaneously?
What they’re really testing: Whether you understand the operational difference between running Burp as a single-user desktop tool versus an enterprise scheduled scanning platform, and whether you’ve thought about multi-tenancy, reporting, and noise management at scale.
Strong answer covers: Separate site configurations per client with strict target scoping to prevent cross-client scan bleed; schedule active scans during client-approved maintenance windows (critical for NZ financial sector clients like Harbour Bank or Pacific Bank where unexpected load on prod is a contractual issue); baseline each app on first scan then configure alerting on net-new findings only — re-alerting on known issues burns analyst time; export findings via the REST API into a central reporting dashboard rather than managing 20+ individual HTML reports.