Burp Suite Tutorial: Your First Intercept to First Finding

What it is and the problem it solves

Burp Suite is an intercepting HTTP proxy and web application testing platform from PortSwigger. You point a browser at it, it forwards every request to the target, and it records what was sent and what came back. That is the whole idea.

The problem it solves is the gap between what a page shows you and what the server accepts. A browser renders an interface and hides the request behind it. Most web vulnerabilities live there: a hidden account identifier, a role field the UI never sends, a price the client calculates. Burp puts you at the wire so you can read, replay and modify those values — and it remains the only practical way to find logic flaws that no scanner can express.

Community Edition is free and gives you the manual toolkit: Proxy, Repeater, Intruder, Decoder, Comparer and the BApp Store. Professional adds Burp Scanner, unrestricted Intruder and Burp Collaborator; Burp Suite DAST is the CI-side product. This guide reflects the current desktop release line, Burp Suite Professional / Community 2026.10. PortSwigger versions by year and release number; both desktop editions share this interface.

Scope and authorisation first. Everything below sends live HTTP to a real server. Before proxying a single request, hold written authorisation naming the hosts in scope, the testing window, the permitted techniques, any rate limits, and what is prohibited — usually denial-of-service testing and destructive actions. Systems you neither own nor have written permission to test are out of bounds, with no exception for “just looking.” Practise on PortSwigger Web Security Academy labs, OWASP Juice Shop, or a local DVWA instance.

Prerequisites

• Written scope and rules of engagement — an artefact, not a verbal go-ahead.
• A few gigabytes of free RAM. The installer bundles its own Java runtime; a separate JDK is only needed for the standalone JAR.
• A dedicated testing browser. Burp’s embedded Chromium is preconfigured to proxy through Burp and already trusts its certificate, so it is the fastest way to start.
• Basic HTTP literacy: methods, headers, status codes, cookies, JSON and form bodies.
• A legal target with two accounts you control, for the worked example below.

Install Burp’s CA certificate only in the throwaway browser profile you use for testing — that certificate lets anything trusting it decrypt traffic.

Setup

1. Download from PortSwigger and run the installer, choosing Community or Professional when prompted, since one installer serves both. Accept the defaults on first launch.
2. Confirm the listener in Proxy → Proxy settings. The default is loopback on port 8080. Keep it bound to 127.0.0.1 unless you have a specific reason otherwise — an open proxy listener is a vulnerability you introduced.
3. Launch Burp’s browser from Proxy → Intercept → Open browser. To use your own, proxy it to 127.0.0.1:8080 and import Burp’s CA certificate from http://burp into that browser profile.
4. Turn interception off. Beginners leave it on and then wonder why pages never load; intercept mode is for deliberate single-request edits.
5. Set scope: right-click the host in Target → Site map, choose Add to scope, then enable the Proxy option that drops out-of-scope traffic so analytics and third-party identity providers never enter your log. That is hygiene and an authorisation control in one setting.

Core workflow

The loop is map, probe, automate, verify.

1. Map. Browse manually with interception off, clicking everything your role allows, including error and settings pages. Requests land in Proxy → HTTP history: your inventory of parameters, cookies, API routes and object references.
2. Probe. Right-click a request, choose Send to Repeater, then change one variable at a time and compare: an identifier, a deleted parameter, a flipped boolean, GET to POST, a swapped content type.
3. Automate selectively. Intruder fuzzes a parameter against a payload list, and Grep-Match flags responses containing errors or another user’s data. Community Edition throttles Intruder’s request rate, so keep payload sets tight.
4. Verify. A different response is not a finding. Re-test, read the body rather than the status code, and confirm the data is not yours.

Also worth knowing: Decoder for base64, URL-encoded and JWT values, Comparer to diff two responses, and the BApp Store for authorization checkers, Logger++ and Param Miner — all free in Community Edition.

Worked example: one IDOR, end to end

Assume you have written authorisation for the target and two accounts: your own (user A) and a second you control (user B). Log in as A, create an order so the application issues a numbered object, then find it in Proxy → HTTP history:

GET /api/v1/orders/1043 HTTP/1.1
Host: shop.example.test
Authorization: Bearer eyJhbGciOi...
Cookie: session=...
Accept: application/json

1. Send that request to Repeater and send it once for a baseline: 200 OK with your order in the body.
2. Change only the identifier — 1043 to 1042 — and resend. A 200 OK containing order 1042’s details is a candidate broken object level authorization (IDOR) finding.
3. Confirm the data is not yours. Look for a different customer name, email or line items you never ordered. A 200 carrying an empty object, a generic error envelope, or your own record again is not a finding — the most common false positive in proxied testing.
4. Prove the boundary from both sides. Log in as B, note B’s object identifier, then request B’s object as A, and A’s as B. This rules out caching and shared-dataset explanations.
5. Test the whole verb set. Replay the identifier with PUT, PATCH and DELETE. Reading someone else’s record and changing it are different severities, and testers routinely stop at the GET.
6. Record it. Save the request and response, redact other users’ personal data, and write the exact sequence: account, request, change, observed result.

The defender’s view of the same request

The tester’s “change one number” is the defender’s authorization question: does this endpoint verify that the authenticated principal owns object 1042 before returning it? If the code fetches a record by identifier and returns it, it does not. Hiding identifiers or switching to UUIDs is not a fix — that is obfuscation, and it fails the moment an identifier leaks through a URL or a log. The fix is a server-side ownership check on every access path, ideally in centralised middleware so a new endpoint inherits the check instead of reimplementing it and missing a branch.

Detection follows the same logic. Sequential object access from one session, clusters of 403 or 404 responses, and one account requesting identifiers that are not its own are all loggable events; most applications record the request and never alert on the pattern. Add authorization regression tests to CI — request another user’s object and assert a 403 — because this bug class returns whenever an endpoint is refactored. A web application firewall will not save you: the request is valid and correctly authenticated.

Reading the results

Burp gives you three sources of evidence with different confidence levels.

• HTTP history is ground truth about what your browser did: use it to spot parameters the interface never exposes and API routes the front end calls but never links.
• Repeater is ground truth about how the server behaves when you ask differently. Most confirmed manual findings come from here.
• Burp Scanner (Professional) generates leads, not findings: reflected-input issues are often mislabelled as XSS, timing issues need a clean baseline, and flagged access control problems still depend on whose data came back.

Prioritise by impact: broken access control and authentication, then injection with a demonstrable effect, then session hygiene, then informational items. In the write-up, give the endpoint, the exact request, the observed response, the business impact and a concrete remediation — not a severity score standing in for an argument.

Limitations

• Community Edition has no automated scanner and throttles Intruder. You get the complete manual toolkit and the BApp Store, but crawling and fuzzing are deliberately rate-limited — plan targeted requests, not wordlists.
• Burp Collaborator is a Professional feature. Out-of-band bugs — blind SSRF, blind XXE, blind SQL injection, some deserialization issues — are confirmed by inducing the target to call back to a listener you control. On Community Edition you supply that listener yourself.
• A proxy only sees HTTP. Infrastructure, TLS configuration, pinned-certificate mobile clients, and logic that happens entirely in JavaScript need other tools or a real browser in the loop.
• The limitation experienced testers raise first: coverage is subjective. A proxy cannot tell you what you failed to test. Burp records everything you touched and nothing you did not, so a manual engagement is only as good as the time budgeted and the hypotheses the tester brought. Authorization work needs an explicit matrix of roles against endpoints, extension-assisted where necessary. “We ran Burp” is not a statement about coverage.

Start small: on a lab target you are authorised to use, intercept a login, change one parameter in Repeater, and explain the difference. Intercept, modify, compare, verify — that loop is the entire method.