# How to get started with bug bounty [2026]: legally finding and reporting vulnerabilities on HackerOne and Bugcrowd

> An explanation of how to get started with bug bounty — the legitimate route by which white-hat hackers earn rewards — faithful to the official sources (HackerOne / Bugcrowd / disclose.io). It covers the difference between bug bounty and VDP, how to read the all-important scope and safe harbor, the correct workflow of recon → verification → report → triage → disclosure, severity (Bugcrowd VRT) and how to write a report that gets through, and even implementing a scope guard that 'structurally refuses out-of-scope.'

- Published: 2026-06-28
- Author: 友田 陽大
- Tags: セキュリティ, ホワイトハッカー, バグバウンティ, 倫理的ハッキング, 脆弱性開示
- URL: https://tomodahinata.com/en/blog/bug-bounty-getting-started-hackerone-bugcrowd-scope-report-disclosure-guide
- Category: Intro to ethical hacking
- Pillar guide: https://tomodahinata.com/en/blog/white-hat-hacker-ethical-hacker-how-to-become-certification-roadmap-guide

## Key points

- Bug bounty is the legitimate route of 'investigate only the range (scope) a company permits, and earn a reward if you find something.' Safe zone ③. It's legal precisely because there's permission; out-of-scope is outside safe harbor = can be illegal.
- The most important skill isn't attacking power but 'the ability to accurately read scope and safe harbor.' Only by observing in-scope/out-of-scope and forbidden techniques (DoS, social engineering, exfiltrating others' data) does legal protection take effect.
- The workflow is recon → discovery → minimal PoC verification → report → triage → reward → coordinated disclosure (CVD). Don't destroy, don't exfiltrate data, don't publish without permission. This is the minimum condition of being white-hat.
- Severity is made a common language by industry standards like Bugcrowd VRT. A report is 'conclusion first, reproducible, impact concrete.' A report that gets through to the developer who fixes it makes the difference in evaluation.
- Guarantee ethics with code: implement a 'scope guard' that judges whether a target is in scope and always stops if out. Make testability a program's invariant, not human memory (default deny).

---

Once you've built up your skills in your own lab and CTFs, it's finally your turn to touch a **real target.** And the only entrance to do that **completely legally** is **bug bounty.**

Bug bounty is a system where a company publishes "you may investigate this range, and we'll pay a reward if you find something." It's exactly the **safe zone ③ (a permitted scope)** defined in [white-hat hackers and the law](/blog/ethical-hacker-law-japan-unauthorized-access-act-active-cyber-defense-disclosure-guide). This article explains the legitimate way to walk to earn rewards, faithful to the official sources (HackerOne / Bugcrowd / disclose.io).

> This is a spoke that digs into the practical/monetization part of [how to become a white-hat hacker [complete roadmap]](/blog/white-hat-hacker-ethical-hacker-how-to-become-certification-roadmap-guide).

---

## 1. The difference between bug bounty and VDP

First, let's organize the terms. There are two that are similar but different.

| System | Purpose | Reward | Character |
|---|---|---|---|
| **Bug Bounty** | Have vulnerabilities found | **Yes** (money according to severity) | Competitive, monetizable |
| **VDP (Vulnerability Disclosure Program)** | A window to safely receive reports | None as a rule (acknowledgment, hall of fame, etc.) | A "receptacle" for good-faith reports |

In [Bugcrowd's definition](https://www.bugcrowd.com/glossary/vulnerability-disclosure-program-vdp/) too, a VDP is distinguished as "providing a safe path for reports," and bug bounty as "motivating researchers with rewards." For beginners, it's safe to **first learn 'the manners of reporting' with a VDP or a beginner-oriented program, and once accustomed, move** to a rewarded one.

---

## 2. Platforms — where to start

It's tough for an individual to suddenly deal directly with a company. What stands in between is a **bug bounty platform.**

- **[HackerOne](https://www.hackerone.com/)** — the largest. Programs of many famous companies gather. The operation of coordinated vulnerability disclosure (CVD) is well-established ([HackerOne CVD](https://docs.hackerone.com/en/articles/9829406-coordinated-vulnerability-disclosure)).
- **[Bugcrowd](https://www.bugcrowd.com/)** — another major one. It publishes the industry standard for severity evaluation, **[VRT (Vulnerability Rating Taxonomy)](https://bugcrowd.com/vulnerability-rating-taxonomy).**
- **[Internet Bug Bounty](https://www.hackerone.com/)** — a joint program targeting OSS / the software supply chain.

The platform mediates everything from **presenting the scope, receiving reports, triage, paying rewards, to coordinating disclosure.** The researcher registers and moves after reading each program's **scope and rules.**

---

## 3. The most important skill is "the ability to accurately read scope"

It may surprise you, but what you should first hone in bug bounty is **not attacking power but "the ability to accurately read scope and safe harbor."** Get this wrong and, far from a reward, it becomes an illegal act.

Each program always states the following.

- **In-Scope** — assets you may test (domains, APIs, apps). There are also wildcard designations like `*.example.com`.
- **Out-of-Scope** — assets forbidden to test (third-party services, specific subdomains, etc.).
- **Forbidden techniques** — **DoS/DDoS, social engineering, physical intrusion, exfiltrating other users' real data**, etc., are clearly forbidden in many programs.
- **safe harbor** — the promise that "no legal action is taken against good-faith research that observes the scope and rules." [disclose.io](https://disclose.io/) is advancing standardization.

> **The fatal point:** **safe harbor takes effect only when "in scope AND rule-compliant."** The moment you touch out of scope, or the moment you use a forbidden technique, that protection vanishes and it turns into the Unauthorized Access Act issue seen in [white-hat hackers and the law](/blog/ethical-hacker-law-japan-unauthorized-access-act-active-cyber-defense-disclosure-guide).

---

## 4. [Implementation] Make the scope judgment "a code invariant"

Relying on human memory for "may I test this" will cause an accident someday. Make it **a program's invariant.** The following is a scope guard that judges whether a target is in scope and **always stops if out (default deny).** Out-of-scope takes priority over in-scope, and it supports wildcards too.

```python
"""scope_guard.py — バグバウンティのスコープ内かを判定し、外なら必ず止める。

設計意図: 「テストしてよいか」を人間の記憶ではなく、プログラムの不変条件にする。
スコープ定義（in/out）を唯一の真実源として、対象ホストを照合する。
out-of-scope への作業は safe harbor の外＝違法になり得るため、デフォルト拒否。
"""

from __future__ import annotations

import sys
from dataclasses import dataclass
from fnmatch import fnmatch
from urllib.parse import urlparse


@dataclass(frozen=True, slots=True)
class Scope:
    """プログラムのスコープ。in/out はワイルドカード可（例: *.example.com）。"""

    in_scope: tuple[str, ...]
    out_of_scope: tuple[str, ...]


def host_of(target: str) -> str:
    """URL でもホスト名でも、判定対象のホストを取り出す。"""
    parsed = urlparse(target if "//" in target else f"//{target}")
    host = (parsed.hostname or "").lower()
    if not host:
        raise ValueError(f"対象からホストを特定できません: {target!r}")
    return host


def is_authorized(target: str, scope: Scope) -> bool:
    """in-scope に一致し、かつ out-of-scope に一致しないときだけ True（デフォルト拒否）。"""
    host = host_of(target)
    # 除外が最優先：out-of-scope に一致したら、in-scope を見るまでもなく拒否。
    if any(fnmatch(host, pattern) for pattern in scope.out_of_scope):
        return False
    return any(fnmatch(host, pattern) for pattern in scope.in_scope)


def main(argv: list[str]) -> int:
    if len(argv) != 2:
        print("usage: python scope_guard.py <target-url-or-host>", file=sys.stderr)
        return 2
    # 実運用では各プログラムのポリシーから読み込む。ここは構造を示す例。
    scope = Scope(
        in_scope=("*.example.com", "api.example.com"),
        out_of_scope=("blog.example.com", "*.corp.example.com"),
    )
    try:
        authorized = is_authorized(argv[1], scope)
    except ValueError as error:
        print(f"判定不能: {error}", file=sys.stderr)
        return 2
    if authorized:
        print(f"IN SCOPE: {argv[1]} — テスト可（プログラムのルールも必ず順守）")
        return 0
    print(f"OUT OF SCOPE: {argv[1]} — テスト禁止（safe harbor の外）", file=sys.stderr)
    return 1


if __name__ == "__main__":
    raise SystemExit(main(sys.argv))
```

```bash
python scope_guard.py https://api.example.com      # IN SCOPE: ... — テスト可
python scope_guard.py https://blog.example.com     # OUT OF SCOPE: ... — テスト禁止
python scope_guard.py https://victim.test          # OUT OF SCOPE（in-scope に一致しない＝デフォルト拒否）
```

The key point of the design is **"prioritize exclusion (out-of-scope) and pass only explicitly permitted targets (default deny)."** It uses the basic security principles of "fail-safe defaults / least privilege" directly to guarantee ethics.

---

## 5. The correct workflow — from recon to coordinated disclosure

Let me organize the series of steps to earning a reward, in line with [HackerOne's coordinated vulnerability disclosure (CVD)](https://docs.hackerone.com/en/articles/9829406-coordinated-vulnerability-disclosure).

```text
1. スコープ精読   in/out・禁止手法・safe harbor を読む（ここが9割）
2. 偵察           in-scope の資産・機能を把握（公開情報の範囲で）
3. 発見           脆弱性の“仮説”を立てる（A01 アクセス制御が最頻出）
4. 検証(PoC最小)  再現に必要な最小限だけ。破壊せず・データを持ち出さない
5. 報告           プラットフォーム経由で、伝わるレポートを提出
6. トリアージ     企業/トリアージャが深刻度を判定（VRT 等）
7. 報奨           深刻度に応じた支払い
8. 協調的開示     修正後、企業と“合意の上で”公表（無断公表しない）
```

In particular, **4 (verification)** is the dividing line. Beyond "the minimum needed for proof" — pulling data, affecting other users, stopping the service — these are rule violations and cross the white-hat line. **Stopping at just "showing you can break in"** is the professional way.

---

## 6. A report that gets through, and severity

As much as technical skill, **a report that gets through to the developer who fixes it** makes the difference in evaluation. Severity is made a common language by [Bugcrowd VRT](https://bugcrowd.com/vulnerability-rating-taxonomy) and CVSS, and attaching a self-assessment along these lines moves the discussion along faster.

The skeleton of a report is **"conclusion first, reproducible, impact concrete."**

```markdown
## 概要（Summary）
注文APIに認可不備（IDOR / A01:2025）。一般ユーザーが ID 改変だけで
他人の注文情報を閲覧できる。

## 深刻度（Severity）
Bugcrowd VRT: P2 相当 / CVSS 4.0 自己評価ベクタを併記（最終判定はベンダー）。

## 再現手順（Steps to Reproduce）
1. 一般ユーザーでログイン
2. GET /api/orders/1001 を GET /api/orders/1000 に変更
3. 他人の注文が返ることを確認（※自分のテスト用に作った注文間で確認）

## 影響（Impact）
全顧客の注文履歴（氏名・住所・購入物）が閲覧可能。情報漏えい。

## 想定される修正（Suggested Fix）
サーバ側で「注文の所有者 == 認証ユーザー」を必ず検証する。

## 証跡（Proof of Concept）
リクエスト/レスポンス例（実データはマスキング）。破壊的操作はしていない。
```

The **IDOR (A01:2025 broken access control)** exemplified here is the typical one found most often in bug bounty and **undetectable by automated tools.** The thinking on detection is detailed in [Next.js × Supabase broken-authorization / IDOR detection](/blog/nextjs-supabase-idor-broken-authorization-rls-detection-guide).

---

## 7. Cautions when participating from Japan

- **Language**: many programs are in English. Reports are basically in English too. Templating them lets you compete just fine.
- **Tax**: rewards are income. Process them appropriately per Japan's tax system, such as filing a tax return (this article is not legal/tax advice — confirm with an expert).
- **Law**: even in scope, Japanese law can reach acts executed from Japan. Absolutely don't deviate from **"the permitted range and permitted techniques."**

---

## 8. What you must not do (a keepsake checklist)

- ❌ Touch **out-of-scope** assets (outside safe harbor = legal risk).
- ❌ Stop the service with **DoS / high-load scans.**
- ❌ View or exfiltrate **other users' real data** (do PoC between your own test accounts).
- ❌ **Publish without permission** / expose on SNS (stay silent before the agreement of coordinated disclosure).
- ❌ Press a company with **"I'll publish unless you pay"** (extortion = a crime).
- ✅ Read the scope and rules → verify minimally → report so it gets through → disclose upon agreement.

---

## 9. Conclusion — build track record and rewards with "the permitted real thing"

- Bug bounty is **safe zone ③.** It's legal because there's permission, and **out-of-scope is illegal.**
- What to hone first is **the ability to read scope and safe harbor** more than attacking power. Guarantee **default deny** with code.
- The workflow is **recon → minimal verification → report that gets through → coordinated disclosure.** Don't destroy, don't exfiltrate, don't publish without permission.

A bug-bounty track record works strongly in the market as **"hands-on proof"** alongside certifications (→ [which certification to get](/blog/ethical-hacker-certification-comparison-ceh-oscp-security-plus-pentest-plus-toroku-sec-guide)). How that skill connects to career, salary, and projects is explained in [white-hat hacker work, salary, and career](/blog/ethical-hacker-career-path-salary-job-roles-freelance-guide).

> **For companies:** "we'd like to start a bug bounty or VDP ourselves too," "before that, we'd like an expert to diagnose pre-production vulnerabilities once" — both are areas needing the involvement of a human who understands the design. The most cost-efficient order is to first wipe out horizontal holes with free OSS, then route the vertical risks that only design can protect to an audit.

---

### References (official primary sources)

- [HackerOne](https://www.hackerone.com/) / [HackerOne coordinated vulnerability disclosure (CVD)](https://docs.hackerone.com/en/articles/9829406-coordinated-vulnerability-disclosure)
- [Bugcrowd](https://www.bugcrowd.com/) / [Bugcrowd VRT (severity classification)](https://bugcrowd.com/vulnerability-rating-taxonomy) / [What is a VDP](https://www.bugcrowd.com/glossary/vulnerability-disclosure-program-vdp/)
- [disclose.io (safe harbor standardization)](https://disclose.io/) / [IPA vulnerability-related information reporting](https://www.ipa.go.jp/security/vuln/report/) / [JPCERT/CC](https://www.jpcert.or.jp/)