Choosing the ‘Right’ Bug Bounty Program

The bug bounty industry can be considered as one of the most competitive industries. The combination of evolving technologies as well as the increasing number of researchers creates a highly competitive environment. In this article, I will be explaining my thought process on how I choose the ‘right’ bug bounty program as a newcomer to increase my chance of finding valid security vulnerabilities.

Image for post
Image for post
Bug Bounty Life

According to Hackerone’s ‘The 2020 Hacker Report’, a soaring number of more than 600,000 new hackers have registered to the platform as of February 2020. This shows that security crowdsourcing is a rapidly growing industry. Among those 600k new hackers, I am one of them! I have been in the bug bounty industry since the beginning of 2020 and have enjoyed every moment since. I have submitted multiple valid vulnerabilities to domestic (Indonesia) as well as international companies. Now, one of the main obstacles that I encountered during my bug bounty journey is finding the appropriate program. There is no right or wrong way in choosing a bug bounty program, but these are the considerations that increase my chance of finding valid security vulnerabilities.

When choosing the ‘right’ bug bounty program, I would always consider the following:

  1. Service Location
  2. Program Launch Date
  3. Resolved Reports
  4. Domain & Vulnerability Scope

For the first 1.5 months of my bug bounty journey, I decided to participate in one of the most well-known programs on HackerOne, GlassDoor. Based on the policy page, Glassdoor rewards security researchers with an above-average bounty while having a good average response time. After a full 1.5 months, I was only able to find 1 HTML Injection Vulnerability, and you guessed it right, duplicate. At this point, I felt really discouraged and began questioning myself. There could only be a few scenarios of why this is happening.

  1. I haven’t learned enough vulnerability classes to find one on Glassdoor.
  2. Many researchers are participating/participated in the program, therefore making it very competitive.
  3. The program might not be the right fit for me (Tech stack, scopes and etc.).

At that time, I would say that the last 2 scenarios described my ‘failure’ the most. I began changing my methodology as well as being very selective when selecting a bug bounty program. I started considering all of the metrics given by HackerOne to researchers such as; Program Launched Date, Scopes, Resolved Reports and etc., hence the consideration factors listed above.

Image for post
Image for post
Narrow Your Competition by Checking Service Location

Moving to our first consideration, Service Location. As we all know, some companies offer services only to a specific region. As an example, companies such as Grab is only available for customers who are living in Indonesia, Singapore, Myanmar, Thailand, Cambodia, and Vietnam, meaning people who are living within these 8 countries would have easier and complete access to the resources and services Grab provides, therefore increasing the chance of finding valid security vulnerabilities. In terms of competition, you will most likely be competing with fewer people than companies that provide services to people around the world. I have also gone to the extreme of participating in companies that are not listed on the HackerOne Programs, meaning companies that are running their own bug bounty program locally. Use these companies as your training ground and knowledge check.

Program Launch Date is another metric that I would closely consider. The newer the program the more undiscovered security vulnerabilities. The later the program the more discovered vulnerabilities. Although it is desirable to hack on new programs, you should be mentally ready to receive duplicates. This is a predictable outcome since many researchers would be participating in the program too. I personally enjoy hacking on programs that have been on the platform for around 4–6 months. At this point, multiple reports must’ve been disclosed, which is another factor to look at. It is really advantageous for researchers to read these reports. Disclosed reports will allow researchers to gain internal knowledge such as technology stack, executable payloads, and etc. unless the company runs a ‘semi-private’ program, reports are redacted entirely.

Lastly, I would urge every researcher to consider the domain and vulnerability scope of the program. If we are going for a horizontal approach, meaning we are searching for a specific vulnerability on different companies, be entirely sure that it is part of the vulnerability scope. If we are going for a vertical approach, then more domains/subdomains are favorable, therefore check the domain scope of the program. Having both would be the most optimal scenario since it will widen the attack surface.

Image for post
Image for post
Just Do It!

In conclusion, the first step to finding vulnerabilities is to just do it, Nike. You will find duplicate or informative reports, but at least you are on the same page as other researchers. This will also serve as foundational building blocks for your bug bounty career ahead as it will enrich your knowledge regarding different vulnerabilities on different technologies. When it comes down to execution, think out of the box, read a lot of writeups, and study from different books. I would recommend watching bug bounty videos on Youtube to motivate yourself. Namasec, Stok, and The Cyber Mentor are channels that give insightful information regarding infosec. Thanks for lending your time!

Cybersecurity enthusiast! Eager to learn and share personal experiences with all of you.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store