A structured lesson workspace with readable content, hands-on examples, and a clean path to completion.
The source treats a bug bounty policy as an operational document: it tells researchers what the organization expects and what may be tested. Its scope section can identify web domains, mobile applications, IP ranges, and other assets. Reading this material carefully is therefore a prerequisite to testing, because a valid technique against the wrong target is still outside the authorized boundary.
| Policy area | Question to answer before testing |
|---|---|
| Scope | Which domains, applications, IP ranges, and vulnerability classes are in scope? |
| Out of Scope | Which targets or issue types must be avoided? |
| Rules of Engagement | What testing behavior is permitted or prohibited? |
| Access | How are research accounts created or obtained? |
| Reporting Format | What evidence and structure does the program expect? |
| Safe Harbor / Legal Terms | What protections or conditions does the organization publish? |
A useful way to read a policy is to convert each section into a decision. Scope becomes a target list. Out-of-scope becomes a deny list. Access becomes an account setup task. Reporting format becomes a submission checklist. Response SLAs become an expectation for communication. This is more useful than reading the page once and then trying to remember it during testing.
The source specifically advises researchers to read the policy and code of conduct meticulously because misunderstandings can cause unnecessary back-and-forth and consume time.
Eligibility rules can affect whether your report qualifies for recognition or reward. Responsible disclosure rules can define disclosure timelines and coordination. Contact information defines the official communication route. These details may feel administrative, but they influence what evidence you collect and how you submit it.
Target: [exact in-scope asset]Access: [research account method]Testing rules: [allowed / prohibited behavior]Out of scope: [explicit exclusions]Submission channel: [official channel]Disclosure notes: [published timeline or coordination rule]
The record above is deliberately descriptive rather than a universal policy template. Every program can structure its rules differently. The important skill is preserving the organization's own wording and converting it into operational constraints before you test.
A strong researcher can answer three questions before testing: What may I touch? What must I avoid? How does the organization want evidence delivered?
Finish the lesson once you have worked through the material. This awards ★ 30 XP.