A Burp Suite workflow that finds real bugs, not just alerts
The scanner is the least interesting part of Burp. This is how we set up scope, authentication and session handling for a web application assessment, which extensions earn their place, and how to tell a finding from a false positive.
Every web application assessment we run goes through Burp Suite, and almost none of the findings that matter come from pressing "Scan". The active scanner is good at the classes of bug that have a deterministic signature: reflected XSS, SQL injection with an error message, path traversal. It is blind to the ones that actually get companies breached, which are about authorisation, business logic and state.
What Burp is genuinely unmatched at is being a place to sit between a browser and an application, with every request in reach. The value comes from how you set it up.
Scope first, or the proxy history is useless
Set the target scope before the first request, and set "and URL in the suite scope" on the proxy interception filter. Otherwise two hours of browsing leaves you with a history full of analytics beacons, CDN fonts and third-party chat widgets, and the request you want is somewhere in it.
Include the application's own hosts and its API host. Exclude the logout endpoint — Burp will hit it during a scan and kill your session at the worst moment.
Authentication is the part people get wrong
An unauthenticated scan of an authenticated application finds the login page. That is the whole result.
Three things need to be right:
Session handling rules. Under Settings → Sessions, add a rule scoped to the target that runs a macro to re-authenticate when the session drops, with a "check session is valid" rule that looks for a string only present when logged in. Without this, half your scan runs as an anonymous user and you never notice.
Multiple identities. Get credentials for at least two users in the same role and one user in a different role, plus an unauthenticated session. Almost every authorisation bug is found by taking a request captured as user A and replaying it as user B.
A token that Burp understands. If the app uses a bearer token in a header rather than a cookie, the macro has to extract it and the session rule has to inject it. It is worth the fifteen minutes; everything downstream depends on it.
The extensions that earn their place
From the BApp store, four do most of the work:
- Autorize replays every request you make as a second, lower-privileged identity and flags the ones that succeed. This single extension finds more real, high-severity bugs in a typical assessment than the active scanner does. Broken object-level authorisation is the most common serious flaw in modern APIs and it is invisible to signature scanning.
- Param Miner guesses unlinked parameters and headers. It is how you find the
?debug=truethat turns on a stack trace and theX-Original-URLthat bypasses the access control at the proxy. - JS Link Finder or JS Miner pulls endpoints, paths and occasionally credentials out of bundled JavaScript. Single-page applications ship their whole API surface to the browser; read it.
- Logger++ gives you a filterable, exportable view across every Burp tool at once, which matters when you need to prove what you sent and when.
Where the findings actually come from
Repeater, one request at a time. Take a request that returns an object by ID and change the ID. Change the user ID in the JWT payload and see whether the signature is checked. Remove the Authorization header entirely. Change the HTTP method from POST to GET. Send the request twice concurrently and see whether the coupon applies twice. None of these are things a scanner infers.
Intruder against identifiers, not passwords. Enumerating sequential object IDs across two accounts tells you the authorisation model in about a minute. Leave credential brute-forcing out of the engagement unless it is explicitly in scope, because it locks out real users and generates alerts the client has to triage.
Comparer on responses. The difference between "user not found" and "wrong password", or between a 200 with 1,240 bytes and a 200 with 1,238 bytes, is frequently the whole finding.
Telling a finding from an alert
Every scanner issue needs three things before it goes in the report: a request you can replay by hand, an observed effect that is not just a reflected string, and a statement of what an attacker gains. "Reflected XSS in the search parameter" with a payload that only fires in a context the CSP blocks is not a finding, it is homework. A stored XSS in a field an administrator views, with a working proof that steals a session, is.
The same applies in the other direction. Burp rates broken access control as low or informational when it rates it at all, because it cannot know that the object behind the ID is another tenant's invoice. Re-rate everything by what the data is worth.
Keep the evidence reproducible
Save the project file, export the relevant Logger++ rows, and write each finding as a curl command the client's own developer can paste into a terminal. A finding that the team can reproduce in thirty seconds gets fixed in the next sprint; one that requires them to install Burp and replay a macro sits in the backlog for a year.
We run this as part of a broader security review, because a web application's bugs and its cloud account's posture usually turn out to be the same story from two ends.