TL;DR
用四個角度讀計畫：範圍、獎勵、排除事項與回報條件。這是閱讀框架，不代表每份規則都只有四個章節。搜尋 scope、reward、exclude、report 後，還要讀前後條款，以及連出去的產品專屬規則。
讀完要留下書面測試計畫：資產、允許方法、帳號與資料邊界、停止條件、回報管道。只找到關鍵字或獎金表，不足以確認測試授權。
情境
你加入新計畫，面前有一大份規則。想開始測試前，得先知道主機是否符合資格、允許哪些動作，以及碰到私人資料時要怎麼處理。
有用的捷徑是整理閱讀順序。跳過條件不會省事：符合範圍的產品，仍可能排除特定方法、版本與漏洞類型。
問題：四個常見卡點
Scope 看不懂。 萬用字元、產品名稱、手機應用程式、路徑與明列的排除事項，可能描述不同邊界。資產歸屬也不等於計畫範圍；整合的第三方服務，不會自動受到主要應用程式的計畫涵蓋。
Rewards 看起來能直接比較。 網頁服務漏洞、TEE 邊界突破與虛擬機逃脫的前提不同。即使都叫「程式碼執行」，最高獎金也不能互相套用。
漏看方法與資料限制。 規則可能限制自動化、請求速率、帳號使用、服務干擾與其他使用者資料。不要拿另一個計畫或一般 API 文件的速率限制，當成這裡通用的規則。
把報告條件看成公式。 清楚的證據有助評估，但 CVSS 字串、修補建議或影片，不會自動換到某個係數。要看計畫實際要求什麼。
解法：四步讀規則
步驟 1：Scope——確認資產與附帶條件
| 範例寫法 | 可能的意思 | 還要向規則確認什麼 |
|---|---|---|
*.example.com | 涵蓋指定子網域的萬用字元 | 是否包含根網域？哪些排除項目優先？ |
example.com | 特定主機或具名資產 | 只包含這個項目，還是也含相關主機？ |
排除清單中的 api.example.com | 這個主機被排除 | 不能假設每個平台都用 ! 表示排除 |
/v1/* | 特定範圍格式中的路徑限制 | 適用哪個主機與哪些方法？ |
| 產品或版本名稱 | 應用程式專屬目標 | 哪些版本、設定與環境符合資格？ |
這些例子是在示範要問什麼，不是一套能套用所有平台的範圍解析器。
- 記下確切資產項目與連結的產品規則。
- 把資產列入測試清單前，先讀排除事項。
- 確認邀請、註冊、測試帳號、版本與環境要求。
- 記錄規則明列的自動化與速率限制；計畫中的動作有疑義，先透過聯絡管道確認再執行。
步驟 2：Rewards——先比較條件，再看金額
| 計畫例子 | 要讀什麼 | 避免怎樣比較 |
|---|---|---|
| Google and Alphabet VRP | 適用資產分級、影響分類、獎金表與明列的報告品質考量 | 把某一分級的最高金額套到所有 RCE 或 XSS |
| Meta Private Processing | 符合資格的攻擊面，以及外部或內部情境條件 | 把外部／內部情境當成報告品質係數 |
| Microsoft Hyper-V | 跨越的邊界、漏洞類型、可運作攻擊的要求與報告品質欄位 | 把 Google 的係數套到 Microsoft 表格 |
查對特定產品與分類的官方頁面，記下網址，以及這個發現必須符合的條件。要引用數字時，分清最高額與預期結果；歷史公告也要和現行規則分開。
有意義的比較先問「這一列要求什麼攻擊者能力與影響」，再問「哪個數字最大」。
步驟 3：Exclusions——把限制轉成停止條件
| 要查的項目 | 在規則中確認的例子 | 實際操作含義 |
|---|---|---|
| 社交工程 | 釣魚、以假身分聯絡員工 | 技術測試邀請，不代表也允許對人測試 |
| 可用性 | 阻斷服務、資源耗盡、壓力測試 | 只用明確允許的方法，發現服務受影響就停止 |
| 第三方 | CDN、身分提供者、整合服務 | 確認另外的授權，不直接繼承範圍 |
| 實體存取 | 裝置修改、現場接觸 | 確認計畫是否允許該情境 |
| 自動化 | 掃描器、暴力嘗試、流量限制 | 使用這個計畫自己的限制 |
| 資料處理 | 私人紀錄、憑證、保存與揭露方式 | 最小化存取、用自己的帳號，依回報指引處理 |
可搜尋 prohibited、not allowed、exclude、social engineering、denial of service、data。真正的規則由前後文決定，這些例子不是每個計畫都適用的排除清單。
步驟 4：Reporting——讓發現可以重現
準備能回答這些問題的證據：
- 涉及哪個符合資格的資產與帳號角色？
- 起始狀態與操作步驟是什麼？
- 應該發生什麼，實際發生什麼？
- 哪些影響已經證明，哪些還是假設？
適合時提供最小 cURL 或 Repeater 操作，遮蔽憑證；附相關回應，不附無關紀錄。計畫要求 CVSS 時，寫清版本與理由，不要每篇都複製一串沒解釋的向量。有依據才提修補建議，截圖或影片能說明操作時再附。
不要為了湊影響數量而下載更多私人資料。能重現的最小例子與清楚的權限邊界，比沒有依據的受影響人數或損失估計更有用。
為什麼這樣讀有效
範圍指出符合資格的攻擊面；測試限制保護服務與其他使用者；回報要求讓發現可以評估；獎勵規則則描述計畫如何處理符合條件的報告。
這幾件事相關，但要分開確認。技術上寫得清楚的報告，仍可能重複或不在範圍內。廣告中的最高獎金，也不會免除表格中那一列的必要條件。
測試前先存下這份紀錄：
計畫與規則網址：
資產／產品／版本：
註冊或邀請條件：
允許的方法與流量限制：
測試帳號與資料邊界：
排除行為與停止條件：
適用獎勵分類與必要條件：
回報管道與要求證據：
尚未釐清的問題：自我檢查
- 我能找到資產項目，以及優先適用的排除事項。
- 我能說明這次測試的方法、帳號與資料。
- 我能解釋適用獎勵列的必要條件，不保證發獎。
- 我記下停止條件與計畫的回報管道。
- 涉及授權疑問的動作，已在執行前釐清。
下一篇第 2 篇會解釋 HTTP、Cookie 與 Session，讓你看懂第 3 篇工作台裡的請求。
更新紀錄
- 2026-10-15：保留有系統的規則閱讀流程並同步兩語，修正萬用字元假設與計畫比較，移除缺乏依據的速率限制、發獎保證與報告品質公式。