A Real Testing Workflow
Watch how a tester drives Burp from scope all the way to a written finding.
What you will learn
- -Sequence a web test from scope to map to probe to exploit
- -Move a request fluidly between history, Repeater, and Intruder
- -Keep notes that survive into the report
You've got a scoped web app, for two low-privilege accounts, and a week. Individual tools you already know. What separates a productive test from flailing is the order you use them in. Here's the loop a working tester runs.
Scope, then map
Add the under Target > and turn on "show only in-scope items". in as user A and click everything: every menu, every form, every filter, the profile page, the export button. You're feeding the site map and history with real requests. Ten minutes of thorough browsing beats an hour of guessing later.
Read the history like a hunter
Open Proxy > HTTP history and cut the noise. Use the Filter bar to hide images, CSS, and JS so you're left with the requests that carry data. Now scan for anything you : an id, a price, a role, a filename, a , an account number. Those are where access-control and injection bugs live. Sort by to group and spot the ones that take input.
Probe in Repeater
Found a juicy one? Send it to Repeater with Ctrl+R and start tampering, one field at a time. Flip id=1001 to id=1002. If user A's session hands back user B's record, that's a broken object-level access control bug (). Change role=user to role=admin. Add a single quote to a parameter and watch for a database error that screams .
Prove it with a second account
A record coming back for id=1002 means nothing until you show it isn't just user A's own data. This is where the second account earns its keep. Log in as user B in a separate browser, grab B's genuine object id, then from A's Repeater session request that exact id. Cross-account access, one user reading another user's data, is the cleanest way to turn a hunch into a confirmed finding.
Scale a single win with Intruder
One IDOR at id=1002 is a bug. Proving the whole range leaks is a severity multiplier. Send the request to Intruder, choose Sniper, set the position on the id, load a Numbers from 1000 to 2000, and run it. Sort by response length and count how many objects come back that shouldn't. Now your report says "enumerable across 800 accounts", not "one record."
Decode and compare when your eyes fail
or URL-encoded token you need to read? Paste it into Decoder. Two near-identical responses you can't eyeball the difference between, like a valid login versus a subtly different failure? Send both to Comparer and let it highlight the delta. Small tools, but they save you from squinting at hex.
The mistake juniors make is testing for three hours, then trying to reconstruct what they did. Don't. The moment a probe works, save the request and response to your notes and write the repro steps immediately. Right-click the item and copy it to a file, record the exact request, the exact response, and the steps to reproduce. Cold findings rot, and a bug you cannot reproduce is a bug you cannot report.
This whole loop sends tampered, enumerating, and fuzzing traffic at a live app. Run it exclusively against systems named in your written , and stay inside the agreed scope the entire time.
In Repeater, changing id=1001 to id=1002 returns another record. What's the fastest way to prove it's a real access-control flaw and not just your own data?