HackerOneで報告するときに気をつけていること

バグバウンティでいちばん時間をかけているのは、実は脆弱性を見つける工程ではなく、報告を書く工程です。トリアージする人が最初の数分で「何が起きて、どこまで影響があるのか」を理解できる報告にしたい。そのために自分に課しているルールを書き出してみます。

1. ポリシーとスコープを、調査の前に読む

当たり前のようでいて、いちばん省略されがちな手順です。プログラムのポリシーには、対象のドメインやアプリだけでなく、やってはいけないこと（自動スキャン、他ユーザーへの影響、ソーシャルエンジニアリングなど）が書かれています。

自分の場合は、ポリシーを読んだ時点で次の3点をメモに残します。

対象（in scope）と対象外（out of scope）の一覧
禁止されているテスト手法
報告に必要とされる情報（例：PoC 動画の要否、テストアカウントの指定）

このメモは調査中に何度も読み返します。「これはスコープ内だろうか」と迷った時点で手を止めるための基準になるからです。

2. 再現手順は「前提を減らす」方向で削る

見つけた直後の再現手順は、たいてい自分の環境に依存した余計な手順を含んでいます。報告に書く前に、次のような問いで削っていきます。

この手順を省いても再現するか
特定のアカウント状態（有料プラン、特定の権限）が本当に必要か
ブラウザ拡張や自作ツールなしで再現できるか

前提が少ないほど、トリアージ側は再現しやすく、影響範囲の見積もりも正確になります。逆に、どうしても必要な前提は必要である理由を添えて書きます。

3. 「確認できた事実」と「推測」を分けて書く

報告の中で最も気をつけているのがここです。

確認できたこと：エンドポイント X に対して、ユーザー A のトークンでユーザー B のリソース ID を指定すると 200 が返り、B のデータが含まれる。

推測：同じパターンが関連エンドポイント Y にも存在する可能性があるが、未検証。

推測を書くこと自体は悪くありません。ただし、推測を事実のように書くと、トリアージ側が検証に時間を取られ、報告全体の信頼性が下がります。見出しや太字で明確に分けます。

4. 影響（Impact）は、攻撃者の視点で一段階だけ進める

「この脆弱性で何ができるか」を書くとき、飛躍しすぎないように気をつけています。IDOR で他人のメールアドレスが読めるなら、まずはその事実と、それがそのプログラムの文脈でどの程度の問題なのかを書きます。「これを起点にアカウント乗っ取りが可能」と書くなら、その経路も同じ精度で検証してから書きます。

5. 証拠は最小限に、しかし十分に

リクエスト／レスポンスは、関係ない部分を削ってから貼る
動画が求められている場合は、短くても手順が追えるものを添える
個人情報が含まれる場合はマスクし、マスクしたことを明記する

6. 自分のためのツールを作る

上の手順を毎回手作業でやるのは大変なので、調査を始める前にスコープを評価し、判断と証拠を監査ログに残す内部基盤を作っています。これは「うっかりスコープ外を触らない」ための安全装置であり、報告を書くときの材料集めにもなっています。

報告の質は、見つけた脆弱性の深刻度と同じくらい大切だと思っています。読む側の時間を減らすことが、結果として自分の報告の評価にもつながります。