Navigating Bug Bounty Policies and Scopes

Hello! Welcome to your next lesson in the final module of your journey.

In our last session, we established the professional groundwork for any security assessment by learning how to define objectives, scope, and the Rules of Engagement (RoE). This framework is what separates a professional, authorized test from random, and potentially illegal, hacking.

Today, we'll sharpen our focus and apply those principles directly to your primary goal: bug bounty hunting. The learning outcome for this lesson is to effectively navigate and interpret bug bounty program policies and scopes. Think of a program's policy page as its unique, non-negotiable RoE document. Mastering the skill of reading and respecting these policies is the single most important factor for long-term success, protecting you legally and focusing your efforts for maximum impact.

The entire bug bounty process begins with understanding the rules, as shown in the diagram below. The 'Scope' is the foundational first step.

1. The "Why" Behind the Rules: Understanding Program Scope

Before we dissect a policy document, it's crucial to understand why these rules exist. They aren't arbitrary obstacles; they are born from complex business, legal, and technical realities. As a future architect, appreciating these underlying reasons will give you a significant professional edge.

A program's scope—the list of what you can and cannot test—is often shaped by factors you can't see from the outside.

Understanding these reasons highlights a key professional principle: respecting the scope is non-negotiable. Going out of scope doesn't just mean your report will be rejected; it can burn your reputation, get you banned from platforms, and in the worst-case scenario, lead to legal trouble. Conversely, building a reputation for respecting rules and providing high-quality, in-scope reports is the fastest way to get invited to private, more lucrative programs.

2. Anatomy of a Bug Bounty Policy

While every program's policy is unique, they generally follow a standard structure. Learning to parse this structure quickly and efficiently is a core skill. A research paper from the Technical University of Munich provides a fantastic, formal taxonomy for the contents of these policies.

Now, let's walk through the most critical sections from that taxonomy, seeing how they look on a real platform.

Practical Walkthrough

First, let's see where to find these policies and what they look like in practice.

Using the taxonomy from the paper and the practical example from the video, let's break down the key components you must analyze.

In-Scope and Out-of-Scope Assets

This is the most important section. It is your legal and operational boundary.

• In-Scope: This lists the domains, IP addresses, applications (web, mobile, desktop), and other assets you are authorized to test. Pay close attention to wildcards (e.g., *.example.com), which mean all subdomains are in scope. The size of the scope can vary dramatically.
• Out-of-Scope: This lists everything you must not touch. Common examples include third-party services (e.g., Zendesk for support, a marketing blog hosted by another company), corporate infrastructure, and specific sensitive environments. Testing out-of-scope assets is the #1 mistake new hunters make.

Eligible and Non-Eligible Vulnerabilities

• Eligible: Programs often list vulnerability types they are particularly interested in, such as SQL Injection, RCE, or significant business logic flaws. These are your high-value targets.
• Non-Eligible (Exclusions): This is a list of findings the program will not accept. Reading this carefully saves you from wasting hours on a report that will be closed as "Not Applicable." Common exclusions include:
  • Findings from automated scanners without proof of impact.
  • Self-XSS (requires a user to hack themselves).
  • Logout CSRF.
  • Missing security headers with no demonstrated exploit.
  • Denial of Service (DoS) attacks.

Prohibited Actions & Submission Guidelines

• Prohibited Actions: Beyond just out-of-scope assets, this section details forbidden behaviors. This nearly always includes:
  • Performing DoS/DDoS attacks.
  • Social engineering or phishing employees.
  • Accessing, modifying, or deleting other users' data.
  • Physical attempts against company property.
  • Heavy automated scanning that could disrupt services.
• Submission Guidelines: The policy will often specify how to format your reports. We will cover this in detail in the next lesson, but always check for specific requirements here.
• Legal "Safe Harbor": Look for a clause that promises the company will not initiate legal action against you if you comply with the policy. This is your "get out of jail free card." If a program doesn't have one, it's a significant red flag.

3. Strategy: Using Policies to Choose Your Targets

A program policy isn't just a list of rules; it's a strategic guide. By analyzing it, you can determine if a program is a good investment of your time and skills.

Based on this, when choosing a target, ask yourself:

1. Is the scope large enough? A larger scope (*.example.com) offers more potential attack surface than a single web app.
2. Does the scope match my skills? If a program only has a mobile app in scope, but you specialize in web apps, it's not a good fit. If they explicitly ask for business logic flaws, and that's your strength, it's a great fit.
3. Are the payouts worth my time? If you're hunting for a living, prioritize programs with higher rewards for critical vulnerabilities.
4. What are the exclusions? If your favorite vulnerability to hunt for is on the out-of-scope list, move on to another program.

Conclusion

You now understand that a bug bounty policy is far more than just "the rules." It's a strategic document that guides your entire engagement with a target. Reading, understanding, and respecting it is the foundation of a successful and professional bug bounty career.

Key Takeaways:

• Policies as RoE: A bug bounty program's policy is its official Rules of Engagement. It defines your legal and technical boundaries.
• Systematic Analysis: Break down policies into key components: in/out-of-scope assets, eligible/ineligible vulnerabilities, prohibited actions, and disclosure rules.
• Business Context Matters: Scopes are defined by real-world business constraints like budgets, M&A activity, and team capacity. Understanding this fosters a professional mindset.
• Strategic Selection: Use the policy to choose targets that align with your skills, goals, and desired reward level. Never waste time on a target without reading its policy first.

Next Lesson Preview:

You've learned the rules, chosen a target, and in a hypothetical future, you've found a valid, in-scope vulnerability. What's next? In our next lesson, we will focus on the most crucial communication skill for a bug hunter: how to write a clear and actionable vulnerability report that includes a description, impact, and remediation steps. A great finding with a poor report can still get you nothing.