A pentester points Burp's automated scanner at a web app, lets it crawl and actively scan overnight, and wakes up to a report with a couple of low-severity missing-header findings and nothing else. "No critical findings" goes in the summary. A month later, someone else spends twenty minutes on the same app by hand and finds that any logged-in user can cancel any other user's order just by changing an ID in the request, broken access control, OWASP's own number one category. The scanner didn't catch it because it structurally can't: finding that bug requires two test accounts and knowing that order 4521 belongs to someone else, not a payload you can throw at a single endpoint.
That gap is the actual lesson, not the specific bug. An automated scan is very good at the OWASP classes that reduce to "does this input produce a recognizable bad response": reflected errors, obvious injection, known-bad headers. It is close to useless at the classes that require understanding what the application's data model means: who owns what, what order operations are supposed to happen in, what a normal user is and isn't allowed to touch. Those are exactly the categories that show up in real breach reports and real bug bounty payouts, and they're the ones a "the scan came back clean" sign-off quietly skips.
Here's how to actually work OWASP Top 10 with Burp instead of just running it against a target and calling that testing.
Use Burp to map the surface, not to scan it
Proxy everything through Burp first and build out the full site map: every endpoint, every parameter, every place an ID, a role, or a state value shows up. This step is manual reconnaissance, not automation, and it's what tells you where the interesting attack surface actually is before you touch a single payload.
Test access control with two accounts, by hand, on every object endpoint
For every endpoint that takes an object identifier, register a second low-privilege account and replay the same request with the other account's session in Repeater. This is the single highest-yield manual step in the entire OWASP list, because it's the one category the automated scanner cannot approximate at all.
Fuzz injection points yourself instead of trusting the active scan alone
Use Intruder or Repeater with your own payload list for SQL injection and command injection candidates rather than relying only on Burp's built-in active scan. The active scanner is tuned for speed across a whole site; a focused manual pass on the parameters that actually look interesting catches variants it's tuned to skip.
Check XSS in the actual rendering context, not just the reflection
A payload reflecting in the response body doesn't tell you whether it executes. Confirm in the browser, and check stored XSS specifically: a comment field, a profile name, anything that gets rendered back to a different user later, since that's the sink an automated crawl often never revisits in the right context.
Treat the scanner as an assistant, not the test
Let it handle the mechanical, high-volume checks and spend your actual attention on the categories it can't reach: authorization logic, multi-step workflows, and anything where the "vulnerability" is really just a check that should exist and doesn't.
This is the difference between a scan and an assessment, and it's exactly what Codelivly's Web Application Hacking Book for Beginners walks through: each OWASP Top 10 class worked manually with Burp Suite, not just described. The free broken access control, reflected XSS, stored XSS, and command injection labs are the same categories to practice hands-on first.
Top comments (0)