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. 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].
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 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 — the largest. Programs of many famous companies gather. The operation of coordinated vulnerability disclosure (CVD) is well-established (HackerOne CVD).
- Bugcrowd — another major one. It publishes the industry standard for severity evaluation, VRT (Vulnerability Rating Taxonomy).
- Internet Bug Bounty — 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 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.
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.
"""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))
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).
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 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."
## 概要（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.
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). How that skill connects to career, salary, and projects is explained in white-hat hacker work, salary, and career.
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.