影響評価 — 重大度を、決める

重大度 = 悪用の可能性(likelihood) × 悪用されたときの影響(impact)
この2つを分けて考えるのがコツです。「発見時にすごいと感じたから重大」ではなく、攻撃者にとってどれだけ容易かと、成功したらどれだけの被害が出るかを、それぞれ別に判断してから掛け合わせます。

前提条件の多さ — ログイン不要で誰でも突けるか、それとも特定の権限を持つ内部者しか突けないか。前者のほうが可能性は高い。
技術的な難易度 — URL を変えるだけ(旗艦の IDOR)か、レースコンディションのように精密なタイミングが要る(sec-logic)か。前者のほうが可能性は高い。
気づかれやすさ — ログに残りやすい/異常検知に引っかかりやすいか。気づかれにくいほど、実行に踏み切られやすい。

機密性 — どんなデータが漏れるか(公開情報か、個人情報か、認証情報か)。
完全性 — データを書き換えられるか(sec-web-basics の反射XSSでの改ざん、sec-logic の価格改ざん)。
可用性 — サービスを止められるか。
影響範囲 — 1人の被害か、全利用者に及ぶか(sec-injection の保存型XSSは「開いた全員」に効くと学びました——これは範囲が広い)。
権限の広がり — その穴から、さらに広い権限(管理者)に届くか(sec-authz の垂直権限昇格)。

反射XSS(旗艦)——未認証でも成立、セッション窃取に直結 → 高。
保存型XSS(sec-injection)——反射型よりさらに影響範囲が広い(開いた全員) → 高。
IDOR(sec-authz)——要ログインだが操作は単純、機密情報が漏洩 → 高〜中(漏れる情報の重さ次第)。
オープンリダイレクト(旗艦)——単独では実害が小さく、フィッシングの踏み台として機能する間接的な穴 → 中〜低。
セキュリティヘッダーの欠落(sec-csp)——単独では実害が薄いが、他の穴の被害を広げる保険の欠如 → 低〜中。

大事なのは、「同じ判定基準を、すべての穴に一貫して当てはめる」ことです。見つけた順に「なんとなく重大」と書くと、報告書全体の優先順位が信頼されなくなります。判定の理由も、可能性と影響に分けて短く書き添えると、依頼主が納得しやすくなります。