📦 MODULE 1: Foundations of Hacking & Bug Bounty 🔹 Chapter 4: Scoping, Rules of Engagement, Disclosure Policies
This chapter is crucial for anyone participating in a bug bounty program. Before you even start looking for vulnerabilities, you must understand the "playing field" and the "rules of the game." Ignoring these guidelines can lead to your report being rejected, your account being banned, or even legal trouble.
1. Scoping: What's In and What's Out?
Scoping is the process of defining the boundaries of a bug bounty program. It tells you exactly what assets (websites, applications, APIs, etc.) are fair game for testing and what assets are off-limits.
* Why is Scoping Important?
* Focuses your efforts: It prevents you from wasting time on assets that are not part of the program.
* Protects the company: It ensures that you don't accidentally test critical, out-of-scope systems that could be damaged or taken offline.
* Clarity for rewards: It ensures that if you find a valid bug, it's in a location where the company is willing to pay a bounty.
* Types of Scopes:
* In-Scope Assets: These are the targets you are allowed to test. They are typically listed explicitly.
* Examples:
* https://www.example.com
* *.example.com (This includes all subdomains like blog.example.com, shop.example.com, etc.)
* example.com's iOS and Android mobile applications.
* The API at api.example.com.
* Out-of-Scope Assets: These are the targets you are not allowed to test. Finding a bug here will not earn you a bounty and could get you in trouble.
* Examples:
* staging.example.com (A testing environment that the company doesn't want you to mess with.)
* partners.example-corp.com (A third-party service that is not owned or managed by the bounty program's company.)
* Vulnerabilities in third-party software (unless they lead to a direct vulnerability in the main application).
* Social engineering attacks against employees.
* Denial-of-Service (DoS) attacks.
Pro-Tip: Always check the scope at the beginning of your research. Scopes can change, so it's a good practice to review them periodically, especially if you're returning to a program after some time.
2. Rules of Engagement: The "How-To" Guide
Rules of Engagement (RoE) are the specific rules and guidelines you must follow while performing your security research. They dictate how you should interact with the in-scope assets.
* Why are Rules of Engagement Important?
* Sets ethical boundaries: They define what is considered "responsible" and "ethical" hacking behavior.
* Prevents service disruption: They help ensure your testing doesn't negatively impact the company's services or its users.
* Protects you legally: By following the rules, you demonstrate good faith and are less likely to face legal consequences.
* Common Rules of Engagement:
* No Automated Scanners: Many programs forbid or heavily restrict the use of automated vulnerability scanners (like Acunetix, Nessus, etc.) because they can generate a large amount of traffic and disrupt services.
* No DoS or Load Testing: Intentionally overwhelming a server to cause a Denial of Service is almost always strictly forbidden.
* No Social Engineering: You are not allowed to trick or manipulate employees or users to gain access to systems.
* Data Handling: If you discover sensitive user data, you must not download, save, or share it. You should stop immediately and report the finding.
* Account Creation: Some programs may require you to use specific email addresses (e.g., @bugbounty.com) or create a limited number of test accounts.
* No Spamming: You should not use the application to send spam or unauthorized messages.
Example:
Imagine a program's RoE states: "Do not create more than two test accounts per day." If you create ten accounts in an hour, your reports could be considered invalid, and your account might be suspended.
3. Disclosure Policies: The "What-If" Guide
Disclosure Policies dictate how and when a vulnerability should be reported and made public. This is a critical step in the bug bounty process, as it ensures that vulnerabilities are fixed responsibly before they are made public.
* Why are Disclosure Policies Important?
* Responsible Vulnerability Management: They provide a structured process for handling sensitive information.
* Builds Trust: They show that the company is serious about security and respects the work of security researchers.
* Prevents Public Exposure: They ensure that a fix is in place before the public knows about the vulnerability.
* Types of Disclosure Policies:
* Full Disclosure (Rare in Bug Bounties): Publicly revealing all details of a vulnerability immediately after discovery. This is generally discouraged and not practiced in bug bounty programs.
* Coordinated Disclosure (Most Common): This is the industry standard.
* Step 1: The researcher finds a bug and reports it privately to the company.
* Step 2: The company acknowledges the report and begins working on a fix.
* Step 3: The researcher and the company agree on a timeline for public disclosure, typically after the fix has been deployed. This could be 30, 60, or 90 days.
* Step 4: Once the fix is in place, the company and the researcher can publicly announce the vulnerability and its solution.
* Non-Disclosure (NDA): Some private bug bounty programs may require you to sign a Non-Disclosure Agreement, which means you can never publicly discuss the vulnerabilities you found.
Example:
You find a critical SQL Injection vulnerability in a company's website. The disclosure policy states: "Report all findings privately. We will aim to fix the issue within 90 days, after which we will coordinate a public disclosure with the researcher." By following this policy, you give the company time to fix the issue, protecting their users from potential attacks. Publicly posting the vulnerability on Twitter before the fix is ready would violate this policy and could lead to your account being banned.
Summary
Understanding Scoping, Rules of Engagement, and Disclosure Policies is the first and most important step in becoming a successful and ethical bug bounty hunter. They are the foundation of a responsible hacking mindset.
* Scoping defines what to test. Always read the scope and only test the assets listed as "in-scope."
* Rules of Engagement define how to test. Follow the rules—do not use automated scanners or perform DoS attacks.
* Disclosure Policies define how to reveal findings. Always report bugs privately and coordinate with the company before any public disclosure.
By mastering these concepts, you can ensure a positive and productive experience for both yourself and the companies you are helping to secure.




