Burp Suite review: alternatives, pricing and tutorial

Burp creates a proxy listener on port 8080 of the loopback interface by default. Open Proxy > Intercept and click Open browser, and Burp launches its bundled Chromium, already configured to send traffic through that listener and to accept Burp’s certificate, so HTTPS is decrypted with no manual setup. Every request and response is recorded in HTTP history, and the Target site map grows as you browse. Intercept pauses a request so you can read or edit it before it leaves. You can use an external browser instead, but that means configuring its proxy and installing Burp’s CA certificate, which is why PortSwigger recommends the bundled one. The browser is updated with Burp itself: 2026.9.2, released on 9 October 2026, moved it to Chromium 154.

Target > Scope holds a list of URL prefixes to include and, beneath them, paths to exclude. Any URL that does not start with an included prefix is out of scope. Advanced scope control replaces prefixes with rules that match protocol, a host regular expression or IP range, a port and a file path. Scope then shapes everything else: history and the site map can show in-scope items only, the proxy can log or intercept in-scope requests only, and the scanner’s live tasks audit in-scope traffic as you browse. PortSwigger’s own guidance lists “you don’t have permission to test” as a reason to exclude a URL. Scope is a project setting, so Professional keeps it in the project file, while Community’s temporary projects lose it when Burp closes.

The desktop editions are built around moving one message between tools. Right-click a request in history and send it to Repeater to edit and resend it, to Comparer to diff two responses, or to Decoder to unpick an encoded value. Sequencer analyses how random a sample of session tokens is. Intruder sends many variations of one request automatically; in Community it is a demo, and the full version is a Professional feature. Burp Collaborator, which detects out-of-band interactions such as DNS lookups triggered by a request, is Professional only. Bambdas, small scripts run from the interface, filter history tables in both editions, and in Professional add custom columns, match and replace rules and Repeater actions.

Burp Scanner is the automated part, available in Professional and Burp Suite DAST but not Community. A scan crawls first, following links, submitting forms and logging in where it has credentials or a recorded login, using a browser so that JavaScript-built pages are reached. It then audits what it found, sending requests and judging the responses. Each issue has a severity (High, Medium, Low or Information) and a confidence (Certain, Firm or Tentative), and those two values are what CI thresholds and triage work from. Scans are driven by scan configurations: built-in presets such as Crawl and Audit - CICD Optimized and Crawl limit - 10 minutes can be stacked, and custom ones saved. BChecks, small custom check definitions, add tests for problems specific to your own application.

Write the scope down before any scan runs, and keep it in version control next to the pipeline. For CI-driven scans that file is burp_config.yml: start URLs, extra in-scope prefixes, and out-of-scope prefixes the scanner must never visit, such as logout, destructive admin functions and third-party services like payment providers that you have no permission to test. The same file picks the scan configuration, the recorded login, the report and the threshold that fails the build. Values written as ${NAME} come from environment variables, so the server URL and API key stay in CI secrets. Generate the full commented template from the scan container with --config-template, using the image tag that matches your DAST version, because PortSwigger warns that a template from a different version may not be compatible. Record the written authorisation for each target alongside the file.

PortSwigger’s ci-driven-scan-github-action (v1.0.2) runs Burp Scanner from the enterprise-scan-container image on the CI runner and writes a JUnit XML report. It needs a Burp Suite DAST licence: either a DAST server with an API user holding the CI-driven scan initiator role, or the no-dashboard mode, where you switch the licence to an API key in your PortSwigger account and copy the URL and key from it. By default the container exits non-zero for any issue of Low severity or above, which fails the job, so set the threshold in burp_config.yml and upload the report with if: always(), or a failing scan leaves no report behind. Run the full crawl and audit nightly after the staging deploy rather than on every pull request, and keep the target a variable that can only name your own environments.

The most durable habit Burp gives a QA team is treating a security bug like any other: a reproducible request, an expected result and a retest. When a scan or a tester finds something, send the request to Repeater, strip it down to what matters, and name the tab after the ticket. Use tab notes to record what the correct response looks like. When the fix is deployed to staging, resend the same tab and compare the old and new responses in Comparer. Group related tabs, such as the login, the request under test and a cleanup call, and send the group in sequence when the check spans several steps. In Professional, save the project file so these tabs survive between sessions; in Community they are gone when Burp closes, so copy the final request into the ticket as well.

Extensions are the way to encode a team’s conventions. This one sets scope from code and highlights every in-scope request, whichever tool sent it, and logs a warning when Repeater or Intruder sends a request outside scope, a cheap guard against testing the wrong host. Build it as a JAR with montoya-api 2026.7 as a compileOnly dependency, in Gradle or Maven, and load it from the Extensions tab. Set the project’s Java version to 21: PortSwigger’s documentation says Burp only runs extensions written in Java 21 or lower. Burp detects the class that implements BurpExtension automatically. Handlers run on every request, so keep them fast and free of network calls. PortSwigger’s starter project and its examples repository are the quickest way to a working build.

A scan is only useful if someone acts on it. In Professional, review each issue’s evidence in the request and response before reporting it, since confidence describes how reliable the detection technique is, not proof; PortSwigger advises confirming reported issues manually. Mark the ones that do not apply as false positives, then generate an HTML report for some or all issues, grouped by type, severity or URL, or export XML, whose per-issue serial numbers help spot new findings across repeated exports. In CI, the JUnit report feeds any test-results viewer, and ignoredIssues in burp_config.yml stops a specific issue on specific paths from failing the build while still recording it. Prefer narrow ignores over raising the threshold. In Burp Suite DAST, triage decisions persist across scans and, from DAST 2026.10, apply to matching issues, which keeps nightly results from resurfacing the same accepted risk.