skip to Main Content
This website use cookies which are necessary to its functioning and required to achieve the purposes illustrated in the privacy policy. To learn more or withdraw consent please click on Learn More. By continued use of this website you are consenting to our use of cookies.

Guest Blog: Best Practices for Quality Bug Hunting by SatishB3

Best Practices for Quality Bug Hunting

As bounty programs offer rewards on a first come first serve basis, bug hunters always seem to be in a hurry to unearth the findings as soon as they can. But before participating in any of these programs, following best practices listed below will benefit you as well as the program owner.

Follow the program rules: Every program defines its own rules, which generally includes,

  • Services in scope (eligible URLs, sub domains, mobile apps, etc.)
  • Eligibility requirements (like country, age, etc.),
  • Qualifying & Non-qualifying vulnerability types
  • Reward amount
  • Disclosure policy
  • Termination rules
  • Submission guidelines, etc.

Before putting your hands on any of the programs, it is important to read and understand the program rules carefully. Following the program rules helps you in focusing on the right target. If you ignore/overlook the rules, you might end up in testing out of scope domains, reporting not eligible bugs and wasting your time. One common mistake many people tend to do even after reading the rules is, use of automated scanners. Many programs do not permit to scan their services using automation tools. Ignoring this rule might result in bounty programs terminating your account or banning you from the program or restricting access to their service by blocking your IP. So always read and adhere to the program rules.

Validate your bugs: Before submitting a bug, validate it thoroughly and make sure that it is reproducible every time. Always crosscheck whether it is an issue at all or an intended feature. Archita covered this topic earlier this week.

Detailed submission: A clear and easy to understand submission definitely helps the program owner in investigating and fixing the issue faster. A detailed report also increases the chances of getting higher rewards for researchers. A detailed vulnerability submission generally includes,

  • Easy to understand description of the bug
  • Location of the bug and detailed steps to reproduce it
  • Explanation of vulnerability Impact
  • Browser/Platform version (ex: Tested from Safari in iPhone 5s – iOS 8.1).
  • Proof of concept code/image/video: Some programs do not like sharing POCs through public file sharing, video streaming sites like Dropbox, YouTube, etc. It is better to communicate with the program owners and find out the appropriate medium that works for them.

Respect other researchers: Often some bounty programs provide a common set of test credentials for researchers. In those cases, allow your fellow researchers to also work on that program and do not change/reset passwords. Appreciate and learn from the good work of other researchers.

Respect program owners: Each program will have its own timelines for validating, fixing bugs and issuing payments. Also, based on the number of reports a program owner receives, the response time may vary. So be patient and never compare with other programs. Always trust and respect the program owner’s decision. If you are not happy with the outcome of your bug report, raise a concern with Bugcrowd and explain. But do not make any threats or use abusive words in the communication or demand for money/swag.

Respect privacy: During research target only the accounts which you have created for testing. Never attempt to gain access or destroy or disrupt another user’s account or data.

Follow the disclosure policies: Some researchers like to disclose full details or share screenshots or write blogs posts about their findings. But before doing so, follow the program’s disclosure policies and disclose the full details only after the bug is fixed. Some programs do not like disclosing the bug details even after the fix is in place. So it is better to approach the program owner before disclosing the bug details to public. I often notice that some researchers disclosing the bug details when their report is marked as duplicate, but doing so does not comply with the program rules.

Test only authorized services: Some people tend to test and report bugs in websites which do not have a bounty or a responsible disclosure program, hoping for money or swag. It is not recommended and might bring legal actions against you.

“Well, we all make mistakes, dear, so just put it behind you. We should regret our mistakes and learn from them, but never carry them forward into the future with us.”
― L.M. MontgomeryAnne of Avonlea

Have some doubts on bug hunting? Catch me at Bugcrowd’s Nullcon 2015 Bug Bash event in Goa, India.


About the Author:

Satish Bommisetty is a passionate security researcher and an author of ‘Practical Mobile Forensics’ book. His primary areas of interests are iOS forensics and mobile application pen testing. He likes to spend his free time with family and in bug hunting. He has reported several vulnerabilities and received acknowledgements from companies such as Google, Twitter, Yahoo, Facebook, PayPal and many more. He maintains a blog at –

Back To Top