Article

Your First Bug Bounty Program – How to Read and Understand the Scope

Many beginners in bug bounty hunting ask the same question: Where do I start?

Logo

Your First Bug Bounty Program – How to Read and Understand the Scope

Many beginners in bug bounty hunting ask the same question: Where do I start?

Finding your first vulnerabilities is challenging enough. Before you are even allowed to test, however, there is one thing you must fully understand: the scope.

The scope defines what you are allowed to test and what is off limits. That sounds simple, but it often causes misunderstandings, especially at the beginning. Ignoring it can result in a rejected report—or even trouble with the program.

Public vs. Private Programs

On platforms such as HackerOne, Bugcrowd, or Intigriti, you will encounter two types of programs:

  • Public: Anyone can participate. These programs are ideal for gaining your first experience.
  • Private: Participation is by invitation only. Fewer researchers are usually active, so your chances are better—but you first need to receive an invitation.

👉 Tip: Public programs are a good way to build a routine when you are starting out. Even if you find “only” duplicates, you can earn points, build your reputation, and improve your chances of eventually receiving invitations to private programs.


Scope – What Are You Allowed to Test?

The scope is the program’s framework. Typical definitions include:

  • *.example.com → all subdomains of example.com are permitted
  • app.example.com → only this specific subdomain is permitted
  • example.com/api/v1/* → only this specific API area is permitted

Important:

  • Always read the scope very carefully.
  • Pay attention to the distinction between in scope and out of scope.
  • “Out of scope” really does mean off limits. Testing there anyway risks not only a rejection, but potentially also a suspension.

Common Pitfalls

Several mistakes are particularly common among beginners:

  1. Wildcard confusion: If the scope lists *.example.com, then test.example.com is permitted—but example.net and example.org are not.
  2. Third-party services: Many companies use external systems such as Cloudflare, payment providers, or help desk software. These are usually out of scope unless the scope explicitly permits testing third parties.
  3. Mobile apps: Just because a company has an app in an app store does not mean you may test it. If the scope only lists the website, leave the app alone.

How Do You Choose a Program to Start With?

  • Not too large: Large programs with wildcards (*.company.com) may look tempting, but can overwhelm beginners. Start with something smaller.
  • Technologies you understand: If you are comfortable with web applications, do not start with IoT or mobile apps.
  • Active programs: Check whether a program has received many recent vulnerability reports. This indicates that it is maintained and takes reports seriously.

Practical Tip: Read the Policies Too

In addition to the scope, programs often have policies with further details:

  • What is rewarded, for example XSS, IDOR, or SQLi?
  • What is not rewarded, for example low-impact issues such as SPF/DMARC or self-XSS?
  • What legal guidance applies?

👉 Many beginners overlook this information. The better you know the rules, the less frustration you will experience with your first reports.


Scope = Your Playing Field

Think of the scope as a playing field:

  • Everything in scope → your playing field.
  • Everything out of scope → red card; keep away.

Once you understand this, you not only avoid unnecessary rejections but also show program owners that you work professionally.


References and Further Reading

  • YouTube: Bug Bounty vs. Pentest → I explain the differences in more detail there.
  • Coming soon: The next article in this series → “Recon for Beginners – How to Find Your First Vulnerabilities”

Conclusion

The scope is more than a formality—it is your guide in bug bounty hunting. Understanding it saves you unnecessary disappointment and futile reports while demonstrating professionalism.

My advice: Take the time to study the scope thoroughly when you begin. Read not only the main page but also the policies. That is often where the decisive details are hidden.

Bug bounty hunting is a marathon, not a sprint—and understanding the scope is the first step toward approaching that journey correctly.