This is the second post in our new series: “Bug Bounty Hunter Methodology”. Today we explore bounty scopes, disclosure terms & rules, and how those guide you in your hacking. If you have any feedback, please tweet us at @Bugcrowd. 

Each bug bounty has a “scope”, or in other words, a section of a bounty program’s details that will describe what type of security vulnerabilities a program is interested in receiving, where a researcher is allowed to test and what type of testing is permitted. On Bugcrowd, a bounty’s scope can be found in the “Program Details” bounty brief section of a program page. It is extremely important to understand the scope and rules of a program, as this is what leads to your bounty being eligible or ineligible for an award.

Disclosure Terms & Rules

A bounty’s disclosure terms are the terms that you’re agreeing to when hacking on a bounty. Bugcrowd has created a Standard Disclosure Terms that many of our programs utilize, though some customers do have alternative versions with specific rules for their program.

These terms describe how to report a bug and outline the disclosure policy for the program. It is very important to understand the disclosure policy of a program, as improper disclosure (ex: publicly disclosing a bug without permission when permission is required) can create undesirable issues for both you and the customer.



The targets for a bug bounty program are the applications & services that you’re allowed to hack on. Make sure to note the finer details in the Targets listing, as there is a big difference between “” and “*”. The asterisk (*) in the sub-domain section of a domain indicates that all sub-domains are in scope, unless otherwise detailed in the Out of Scope section of the bounty brief.

The targets list can and often will include a mix of web, mobile, IoT, API and other targets.


Out of Scope

The out of scope section of a bounty brief lists the types of security findings & bugs that will excluded from the bounty. Many Out of Scope listings will also include types of testing that are not allowed, often including DDoS attacks, phishing and social engineering. Going out of scope of a bounty is risky as it can result in no reward and receiving a negative reputation on the Bugcrowd platform.

If for some reason you wish to go out of scope in your testing it’s best to ask the bounty program owner before you begin. On Bugcrowd you can contact a program owner by emailing and asking for permission to test out of scope and including the reasoning for your request.


The Bounty Brief & Rewards

In addition to the previously detailed sections of a bounty brief, the program details will often include a description of the types of rewards a researcher can expect for a class of bug or a type of security finding. Some programs will also include details for how to test, any credential information that will be required for testing, or otherwise useful information for the researcher.

For more insight into the process of creating a bounty brief and scope from a bounty program owner’s perspective, please read How to Build a Bug Bounty Program: A-Z.