After this lesson, you will be able to: Run a complete professional bug-bounty workflow with Burp: recon to scope, a structured testing methodology, managing the project file, responsible disclosure, writing a great report, and reading program scope on HackerOne/Bugcrowd.
This lesson ties the subtrack together into the workflow of a real engagement. It covers getting recon into Burp, a prioritized testing methodology, organizing findings, writing a report a developer can act on, and the platform mechanics of bug bounty.
Start by gathering the target's subdomains and endpoints with external recon tools, then import them into Burp's target scope so everything is organized and you never stray out of bounds. Reading the program's scope page first (what hosts and vulnerability types are in and out of scope) is non-negotiable; out-of-scope testing voids rewards and can be illegal.
On any new target: map the application (the history/scope lesson), then test systematically by impact. Authentication and access control (IDOR is high-value and common) usually come first, then injection, then business logic, then the advanced classes. Prioritize by likely impact and by what the program rewards, and avoid duplicate finds by checking what has already been reported where possible. A methodology beats ad-hoc poking.
A Burp project file (Professional) saves your entire engagement so you can stop and resume: the site map, history, Repeater tabs, and findings. Organize as you go (labeled Repeater tabs, notes) so that when you find something, you can reconstruct and document it. Export relevant requests/responses for your report.
A good bug report has: a clear title, a severity (use CVSS), an environment, steps to reproduce written so a developer who has never heard of you can reproduce the bug in under ten minutes, a proof of concept (request/response or screenshot), an impact statement in business terms, and a suggested fix. Disclose responsibly through the program's channel and do not publicize before it is fixed. The quality of your report is often what separates a paid, triaged finding from a rejected one.
HackerOne and Bugcrowd are the major platforms; each program has a scope page, a rewards table, and rules. Read them fully before testing. Common beginner mistakes: testing out of scope, submitting low-value informational findings as if critical, vague reports a developer cannot reproduce, duplicate submissions, and getting discouraged by early rejections. Start with programs that welcome beginners, and treat every report as a writing exercise as much as a technical one.
Pick the best answer.
Testing before reading the scope page. Submitting noise (informational findings dressed as critical). Reports a developer cannot reproduce. Not using CVSS, so severity is hand-wavy. Disclosing publicly before a fix. Chasing exotic bugs while ignoring common high-value ones (IDOR, access control). Giving up after early rejections instead of improving report quality.
Sign in and purchase access to unlock this lesson.