找到漏洞之後，你還需要讓別人看懂你發現了什麼。
接手報告的人可能沒用過這個網站，也沒有參與你的測試。他需要靠你的說明重現問題、確認影響，再把問題交給工程師修復。
HackerOne 的官方指南建議提供清楚的標題、重現步驟、影響與必要證據；Bugcrowd 也要求交代漏洞位置、相關操作與 PoC。[1][3]
初學者可以先用五個問題整理報告：
| 問題 | 要交代的內容 |
|---|---|
| What | 發生什麼漏洞？ |
| Where | 漏洞出現在哪個功能或端點？ |
| How | 要怎麼重現？ |
| Proof | 有什麼證據？ |
| Impact | 已經證明能造成什麼影響？ |
這是本文整理的寫作方法，不是平台規定的固定公式。
本文依 HackerOne、Bugcrowd、Intigriti、Google、Microsoft、Dropbox 與 YesWeHack 的官方資料整理。提交時以各專案的規則為準，文末附有官方來源。
一、中文可以寫嗎？先看專案的語言要求
先用中文整理自己的發現，通常有助於把步驟與證據寫完整。至於能不能直接用中文提交，要看平台與專案要求。
Dropbox 在 2015 年 8 月 31 日發布的官方文章中，曾建議不習慣英文的研究員使用母語提交。[10] 這是 Dropbox 當時的建議，不能套用到所有專案，也不能當成它目前所有計畫的語言保證。
Intigriti 目前的提交指南則以英文為優先，除非專案細節另有明示。[5]
實際寫報告時，可以照這個順序：
- 用熟悉的語言整理測試紀錄。
- 確認專案接受的提交語言。
- 需要英文時，再翻譯成英文。
- 對照原始紀錄，檢查帳號、參數、請求、回應與影響有沒有被改錯。
英文不用華麗。你更需要確認的是：對方能不能照著重現？
如果讀者還需要問「去哪個頁面」「登入什麼角色」「改哪個參數」「成功後看到什麼」，就把這些資訊補進報告。
二、一份完整報告可以用這個結構
以下是適合初學者的架構，並非每個平台都要求全部欄位：
| 中文欄位 | 英文欄位 | 用途 |
|---|---|---|
| 標題 | Title | 快速交代漏洞、位置與影響 |
| 摘要 | Summary | 用幾句話說明發現 |
| 測試目標 | Target | 指出網域、端點與參數 |
| 前置條件 | Prerequisites | 說明帳號、權限與必要設定 |
| 重現步驟 | Steps to Reproduce | 讓讀者照著操作 |
| 概念驗證 | Proof of Concept | 提供關鍵請求、程式或其他驗證材料 |
| 預期結果 | Expected Result | 說明應有的安全限制 |
| 實際結果 | Actual Result | 說明觀察到的行為 |
| 安全影響 | Impact | 說明已驗證的影響與限制 |
| 建議嚴重度 | Suggested Severity | 專案要求時，提供評估與理由 |
| 補充證據 | Supporting Evidence | 附上有用途的截圖、影片或紀錄 |
| 修補建議 | Suggested Remediation | 提供合理的修補方向 |
有些平台已經分開提供 Target、Impact 或 Severity 欄位，照平台表單填寫即可，不必把相同內容重複貼很多次。
三、Title：讓人一眼看懂問題
只寫 XSS vulnerability 或 Found IDOR，看不出漏洞位置與影響。
可以用這個格式：
[Vulnerability Type] in [Feature / Endpoint] allows [Verified Impact]
例如：
Stored XSS in Profile Biography allows JavaScript execution when another user views the profile
IDOR in /api/orders/{order_id} allows a regular user to read another user's order details
對應的中文標題：
個人簡介存在儲存型 XSS，其他使用者查看時可觸發 JavaScript
訂單明細 API 存在 IDOR，一般使用者可讀取另一個帳號的訂單資料
HackerOne 的指南也用「漏洞＋具體位置＋執行結果」示範更清楚的標題。[1]
標題寫到證據能支持的範圍。只證明跨帳號讀取，就先寫跨帳號讀取，不要寫成整個資料庫外洩。
四、Summary：用一小段說清楚漏洞
Summary 應該描述目標系統的問題，不需要從漏洞定義開始教起。
中文可以這樣寫：
訂單明細 API 允許 User A 使用自己的登入憑證，讀取 User B 的私人訂單。
測試時，我只修改路徑中的 order_id，保留 User A 的身分驗證資訊，
伺服器仍回傳 User B 的訂單資料。
這個結果是使用我控制的兩個一般使用者帳號驗證的。
英文可以這樣寫：
The order details API allows User A to retrieve User B's private order
using User A's own authentication token.
Changing only the order_id in the request path causes the server to return
User B's order data.
I reproduced this behavior using two regular user accounts under my control.
如果沒看到原始碼，就先描述觀察到的授權失效。不要直接斷言「某個函式忘了檢查 owner_id」，除非你確實有證據。
五、Target：寫到具體的端點與參數
只寫 example.com 不夠，請指出實際測試的位置：
Host:
https://app.example.com
Endpoint:
GET /api/v1/orders/{order_id}
Affected parameter:
order_id（位於 URL 路徑）
Tested role:
Authenticated regular user
如果漏洞與環境有關，再補上實際測試的瀏覽器版本、作業系統、應用程式版本與特殊設定。不要把範例版本直接當成你的測試環境。
Microsoft 的指南要求提供受影響元件與環境資訊；Intigriti 也建議標示端點。[5][8][9]
六、Prerequisites：把前置條件說清楚
需要兩個帳號、特定權限、加入 Workspace 或先建立資料，都要說明。
尤其要區分兩件事：
- 重現時的測試準備：研究員使用兩個自己的帳號，建立資料並驗證歸屬。
- 攻擊者的利用條件：需要一般帳號、另一個帳號的有效訂單 ID 等。
研究員知道 User B 的 ID，不代表真實攻擊者一定能取得它。
例如：
Test setup:
- Two regular user accounts controlled by the researcher.
- One private order created by each account.
Exploitation prerequisites:
- A regular authenticated account.
- A valid order ID belonging to another user.
- No administrative privileges or access to the other user's token.
Google 的品質評估也包含 Attack Preconditions。[7]
七、Steps to Reproduce：一步做一件事
不要把登入、建立資料、擷取請求與修改參數，全塞在同一句話裡。
可以寫成：
- 登入 User A，建立一筆私人訂單，記下 ID。
- 在另一個瀏覽器工作階段登入 User B，建立另一筆私人訂單。
- 確認 User B 能正常查看自己的訂單，並記下 ID。
- 回到 User A 的請求，保留 User A 的 Token。
- 只把路徑中的訂單 ID 改成 User B 的訂單 ID。
- 送出請求。
- 確認回應是否包含 User B 的訂單資料。
帳號切換要交代清楚，避免重現時不小心沿用 User B 的 Cookie 或 Token，誤以為跨帳號讀取成功。
HackerOne 建議使用編號步驟，包含 URL、受影響參數與必要角色。[1]
八、PoC：提供足以驗證的證據
PoC 是 Proof of Concept。依漏洞類型，可以提供 HTTP Request / Response、最小腳本、curl、截圖、影片、Debugger output 或 Crash dump。
例如：
curl --include 'https://app.example.com/api/v1/orders/10002' \
-H 'Authorization: Bearer <USER_A_TOKEN>'
<USER_A_TOKEN> 要替換成 User A 的有效 Token；10002 要替換成 User B 的測試訂單 ID。這是格式示範，不是已驗證的真實漏洞。
如果實際系統使用 Cookie，請提供實際的 Cookie 驗證方式。不要為了套範本，把原本的請求改成系統不支援的 Bearer Token。
Microsoft 把可靠、精簡的 PoC 列為提升報告品質的條件。[8]
九、Expected / Actual：說清楚安全限制
以私人訂單為例，預期行為是：User A 不應取得 User B 的訂單內容。
Expected Result:
The server should deny User A access to User B's private order without
returning its contents.
Actual Result:
The server returns HTTP 200 OK with User B's order data.
不一定只能回傳 403 Forbidden。系統也可能使用 404 Not Found 隱藏資源是否存在；HTTP 標準允許這種做法。[13]
重點是授權限制有沒有守住。單看 200 OK 也不足以證明資料外洩，還要確認回應內容確實是另一個帳號的私人資料。
十、Impact：每個主張都要接得上證據
Impact 要回答：誰在什麼條件下，可以越過哪個限制，取得什麼資料或執行什麼操作？
可以這樣寫：
An authenticated user who obtains another valid order ID can retrieve
that order without the owner's authorization.
In the two-account test, User A retrieved User B's order ID, owner field,
shipping status and shipping address using User A's own token.
如果回應只包含 Email，就不要寫成密碼外洩；如果沒有測試修改訂單，就不要寫成資料竄改。
Intigriti 建議具體說明技術與使用者影響，適用時再補充商業或法遵影響，並提供證據或推理支持。[6]
法遵影響也不能直接寫成「公司一定會被罰款」。是否違法、適用哪些規範與是否裁罰，無法只靠一份漏洞 PoC 判定。
十一、把已驗證結果與推測分開
如果測試只觀察到外部 DNS 查詢，這個結果還不足以證明內網 HTTP 存取、雲端 metadata 讀取或雲端接管。你也需要排除其他元件觸發查詢的可能，不能看到 callback 就認定來源一定是目標應用程式。
其他漏洞也一樣：
- 一次跨帳號讀取，不代表可以匯出全部資料。
- 兩個並行請求成功，不代表能無限取得折扣。
- 購物車顯示折扣，不代表結帳金額真的改變。
- JavaScript 執行成功，不代表已完成帳號接管。
YesWeHack 在 2026 年 8 月 25 日的官方文章中，直接用 DNS、UUID IDOR 與折扣競態範例說明這些證據缺口。[11]
但「只寫已證明的影響」也不代表要為了把影響測到最大，去讀取真實使用者的資料或進行破壞性測試。
如果進一步驗證會超出規則，就交代已知結果、推論依據與驗證限制。Google 的品質規則也明確考慮無法在不違規的情況下完成影響分析的情境。[7]
十二、Severity：寫出判斷理由
嚴重度要依照實際條件與專案規則判斷，不能因為漏洞叫 IDOR，就固定選 Medium 或 High。
| 平台 | 評估方式 |
|---|---|
| HackerOne | 可手動選擇嚴重度或使用 CVSS；專案也可能使用其他方法。[2] |
| Bugcrowd | VRT 提供基準優先級，實際評估會受情境與影響改變。[3][4] |
| Intigriti | 提供 CVSS calculator，也可手動選擇嚴重度。[5] |
| 各 VRP 依計畫規則評估影響與獎金，部分計畫另有報告品質係數。[7] | |
| Microsoft | 依適用的 Bounty Program 與報告品質要求評估。[8] |
HackerOne 官方文件確認，自 2026 年 9 月 21 日起，向要求嚴重度的 Bug Bounty、VDP 與 Challenge 計畫提交報告時，需要選擇 severity。已選擇不要求嚴重度的計畫不受這項要求限制。[2]
判斷時，至少考慮：
- 是否需要登入或特殊權限？
- 是否需要受害者互動？
- 物件 ID 要怎麼取得？
- 能讀取、修改還是刪除哪些資料？
- 資料有多敏感？
- 已證明的影響範圍有多大？
可以提出建議，但要說明理由。若填寫 CVSS，請附上版本與完整向量，並確認各指標符合測試結果。
十三、截圖與影片：讓證據更容易看懂
截圖適合呈現帳號身分、權限差異與實際結果。影片適合多步驟流程、複雜介面或競態操作。
文字中仍要提供必要請求與步驟，避免審核人員只能暫停影片，手動抄寫參數。
Intigriti 的官方指南要求重現所需資訊寫在報告中，附件原則上是補充證據；特殊情況可能有例外。[5]
附上影片時，標示哪個時間點呈現了什麼。附件優先使用平台提供的上傳功能，並確認專案的檔案分享規則。Intigriti 的官方文章提醒，一般不允許使用外部託管與檔案分享服務，技術限制下的例外也有保護要求。[12]
十四、Remediation：提供合理的修補方向
HackerOne 與 Intigriti 都將修補建議列為可提供、但非一律必填的資訊。[1][5]
例如 IDOR 可以寫：
Enforce server-side object-level authorization on every order access.
Verify that the authenticated user is authorized to access the requested
order before returning any order data.
授權可能包含擁有者、委派角色或其他合法存取者，因此不能假設所有系統都只能用「user_id 等於 owner_id」修補。
如果不熟悉架構，就先說明應補上的安全控制，不必指定框架或資料表。不要把換成 UUID 當成授權檢查的替代方案。
十五、中英文都能使用的欄位範本
以下範本保留中英文對照。正式提交時，選擇專案接受的語言，不必每個欄位都重複兩次。
# [漏洞類型／Vulnerability Type] in [功能或端點／Feature or Endpoint] allows [已驗證影響／Verified Impact]
## 摘要 / Summary
[說明觀察到的漏洞、利用條件與已驗證結果。]
## 測試目標 / Target
- Host: [URL]
- Endpoint: [HTTP method and path]
- Affected parameter: [Name and location]
- Tested role: [Account role]
- Environment: [Relevant version or configuration, if needed]
## 前置條件 / Prerequisites
- Test setup: [Accounts and data needed for reproduction]
- Exploitation prerequisites: [Privileges and information needed by an attacker]
## 重現步驟 / Steps to Reproduce
1. [登入與準備資料。]
2. [確認正常行為及資源歸屬。]
3. [使用明確的帳號工作階段，修改指定參數。]
4. [送出請求。]
5. [確認具體結果。]
## 概念驗證 / Proof of Concept
Request:
```http
[Minimal request]
```
Response:
```http
[Relevant response]
```
[交代佔位符如何替換，以及如何取得必要憑證或測試 ID。]
## 預期結果 / Expected Result
[應有的安全限制。]
## 實際結果 / Actual Result
[實際觀察到的行為。]
## 安全影響 / Impact
- Confirmed: [已驗證的資料讀取或操作。]
- Prerequisites: [攻擊成立的條件。]
- Limitations: [未驗證的範圍與限制。]
## 建議嚴重度 / Suggested Severity
[依專案要求填寫等級與理由；使用 CVSS 時附版本與向量。]
## 補充證據 / Supporting Evidence
[實際存在的附件名稱、用途與影片時間點；無附件可刪除此欄。]
## 修補建議 / Suggested Remediation
[應補上的安全控制；不了解根本原因時避免臆測程式實作。]
送出前，將方括號內容換成實際資訊，刪掉不用的提示。
十六、完整中文報告範例：訂單明細 API 的 IDOR
以下是虛構教學案例。網域、帳號、訂單與回應均為示範，不代表已在任何真實網站驗證。情境假設每筆訂單是私人資料，User A 沒有取得 User B 的存取授權。
中文與下一節的英文描述相同案例，方便對照。實際報告要使用自己的測試紀錄，不能照抄這裡的結果。
# 訂單明細 API 存在 IDOR，登入使用者可讀取另一個帳號的私人訂單
## 摘要
User A 使用自己的登入 Token，只要把訂單明細 API 路徑中的 order_id
改成 User B 的有效訂單 ID，就能取得 User B 的私人訂單資料。
我使用兩個自己控制的一般使用者帳號驗證。User A 與 User B 沒有
共享訂單，也沒有互相授權存取。
跨帳號請求回傳了訂單 ID、擁有者欄位、出貨狀態與配送地址。
## 測試目標
- 網域：https://shop.example.com
- 端點：GET /api/orders/{order_id}
- 受影響參數：order_id，位於 URL 路徑
- 測試角色：已登入的一般使用者
## 前置條件
重現測試需要：
- 研究員控制的兩個一般使用者帳號 User A 與 User B。
- User A 建立一筆私人訂單；本次示例 ID 為 10001。
- User B 建立另一筆私人訂單；本次示例 ID 為 10002。
- 使用兩個獨立的瀏覽器工作階段，避免混用 Token。
利用此問題需要：
- 一個已登入的一般帳號。
- 另一個帳號的有效訂單 ID。
- 不需要管理員權限，也不需要另一個帳號的 Token。
本次測試從 User B 自己的訂單頁取得 10002，以驗證資源歸屬。
尚未證明攻擊者在無法登入 User B 的情況下，如何取得其訂單 ID。
## 重現步驟
1. 登入 User A，開啟 https://shop.example.com/orders，建立一筆私人訂單。
2. 開啟 User A 的訂單明細，擷取請求並記下 order_id 與登入 Token。
本次示例的 order_id 為 10001。
3. 確認 User A 使用自己的 Token 請求 10001 時，回應是 User A 的訂單。
4. 在另一個瀏覽器工作階段登入 User B，建立另一筆私人訂單。
5. 開啟 User B 的訂單明細，確認該訂單屬於 User B，並記下 ID。
本次示例的 order_id 為 10002，擁有者欄位為 user_b，
出貨狀態為 processing，配送地址為 TEST_ADDRESS_B。
6. 回到步驟 2 擷取的 User A 請求，保留 User A 的 Token。
7. 只把請求路徑從 /api/orders/10001 改成 /api/orders/10002。
8. 送出修改後的請求。
9. 確認回應為 HTTP 200 OK，且內容包含步驟 5 確認的 User B 訂單資料。
重現時，請使用新建立的測試訂單 ID，不要直接使用範例中的 10001 與 10002。
## 概念驗證（PoC）
正常請求：User A 讀取自己的訂單。
```http
GET /api/orders/10001 HTTP/1.1
Host: shop.example.com
Authorization: Bearer <USER_A_TOKEN>
```
跨帳號請求：只改訂單 ID，仍使用 User A 的 Token。
```http
GET /api/orders/10002 HTTP/1.1
Host: shop.example.com
Authorization: Bearer <USER_A_TOKEN>
```
跨帳號請求的回應：
```http
HTTP/1.1 200 OK
Content-Type: application/json
{
"order_id": 10002,
"owner": "user_b",
"shipping_status": "processing",
"shipping_address": "TEST_ADDRESS_B"
}
```
也可以使用以下指令重現跨帳號請求：
```bash
curl --include 'https://shop.example.com/api/orders/10002' \
-H 'Authorization: Bearer <USER_A_TOKEN>'
```
<USER_A_TOKEN> 需替換成步驟 2 中取得的有效 Token。
TEST_ADDRESS_B 是 User B 測試訂單填入的人工測試資料，不是真實個資。
## 預期結果
伺服器應拒絕 User A 存取 User B 的私人訂單，且不回傳訂單內容。
可依系統設計回傳 403 Forbidden、404 Not Found 或其他適當的拒絕結果。
## 實際結果
伺服器回傳 HTTP 200 OK，並提供 User B 的訂單 ID、擁有者欄位、
出貨狀態與配送地址。
## 安全影響
測試已證明，一般登入使用者在知道另一個帳號的有效訂單 ID 時，
可以使用自己的 Token 跨帳號讀取私人訂單，造成未經授權的資料揭露。
本次驗證範圍為兩個研究員控制的帳號與一筆跨帳號訂單讀取。
沒有使用 User B 的 Token 送出跨帳號請求。
尚未驗證訂單 ID 的其他取得方式、大量列舉、全站資料外洩、
修改訂單、刪除訂單或帳號接管。
## 建議嚴重度
初步建議：Medium，最終依專案規則與完整影響評估。
理由：需要登入並取得另一個帳號的有效訂單 ID，但不需要管理員權限。
已驗證私人訂單資料的跨帳號讀取；尚未證明大量取得 ID 或擴大影響範圍。
若專案要求 CVSS，應依實際 ID 取得條件與資料敏感程度補上版本及向量。
## 修補建議
在每次訂單讀取前執行伺服器端的物件層級授權檢查，
確認目前登入者有權存取該筆訂單，再回傳資料。
不要只依賴前端隱藏訂單、使用者已登入，或訂單 ID 不容易猜測。
修補後以兩個一般帳號確認：合法存取仍正常，跨帳號的未授權請求會被拒絕。
範例的 Medium 是這個虛構情境的初步建議，沒有主張它適用所有 IDOR。沒有實際附件，因此範例也沒有虛構截圖名稱。
十七、完整英文報告範例：相同 IDOR 案例
# IDOR in Order Details API allows authenticated users to read another account's private order
## Summary
User A can retrieve User B's private order by changing the order_id in the
order details API request while keeping User A's own authentication token.
I reproduced the issue using two regular user accounts under my control.
The accounts do not share orders and have not granted each other access.
The cross-account response contains the order ID, owner field, shipping
status and shipping address.
## Target
- Host: https://shop.example.com
- Endpoint: GET /api/orders/{order_id}
- Affected parameter: order_id in the URL path
- Tested role: Authenticated regular user
## Prerequisites
Reproduction setup:
- Two regular user accounts, User A and User B, controlled by the researcher.
- One private order created by User A; the example ID is 10001.
- A separate private order created by User B; the example ID is 10002.
- Separate browser sessions to avoid mixing authentication tokens.
Exploitation prerequisites:
- A regular authenticated account.
- A valid order ID belonging to another account.
- No administrative privileges or access to the other account's token.
For this test, I obtained order ID 10002 from User B's own order page to
verify ownership. I have not demonstrated how an attacker would obtain
that ID without access to User B's account.
## Steps to Reproduce
1. Log in as User A, navigate to https://shop.example.com/orders and create
a private order.
2. Open its details and capture the request, order_id and authentication
token. The example order_id is 10001.
3. Confirm that requesting order 10001 with User A's token returns User A's
own order.
4. In a separate browser session, log in as User B and create another
private order.
5. Open its details, confirm that it belongs to User B and record the ID.
The example order_id is 10002. Its owner field is user_b, shipping
status is processing and shipping address is TEST_ADDRESS_B.
6. Return to the User A request captured in step 2. Keep User A's token.
7. Change only the request path from /api/orders/10001 to /api/orders/10002.
8. Send the modified request.
9. Observe HTTP 200 OK and the User B order data verified in step 5.
When reproducing the issue, replace 10001 and 10002 with the IDs of your
newly created test orders.
## Proof of Concept
Baseline request: User A reads their own order.
```http
GET /api/orders/10001 HTTP/1.1
Host: shop.example.com
Authorization: Bearer <USER_A_TOKEN>
```
Cross-account request: only the order ID changes; User A's token is retained.
```http
GET /api/orders/10002 HTTP/1.1
Host: shop.example.com
Authorization: Bearer <USER_A_TOKEN>
```
Cross-account response:
```http
HTTP/1.1 200 OK
Content-Type: application/json
{
"order_id": 10002,
"owner": "user_b",
"shipping_status": "processing",
"shipping_address": "TEST_ADDRESS_B"
}
```
The cross-account request can also be reproduced with:
```bash
curl --include 'https://shop.example.com/api/orders/10002' \
-H 'Authorization: Bearer <USER_A_TOKEN>'
```
Replace <USER_A_TOKEN> with the valid token captured in step 2.
TEST_ADDRESS_B is synthetic data entered into User B's test order, not
real personal information.
## Expected Result
The server should deny User A access to User B's private order without
returning its contents. Depending on the application's design, an
appropriate denial may use 403 Forbidden, 404 Not Found or another response.
## Actual Result
The server returns HTTP 200 OK with User B's order ID, owner field,
shipping status and shipping address.
## Impact
The test demonstrates that a regular authenticated user who knows another
account's valid order ID can read that private order using their own token,
resulting in unauthorized disclosure of order data.
The test covered two researcher-controlled accounts and one cross-account
order read. User B's token was not used for the cross-account request.
I have not demonstrated other ways to obtain order IDs, large-scale
enumeration, disclosure across the entire user base, order modification,
order deletion or account takeover.
## Suggested Severity
Initial suggestion: Medium, subject to the program's rules and full impact
assessment.
The attack requires authentication and another account's valid order ID,
but no administrative privileges. Cross-account access to private order
data was confirmed; obtaining IDs at scale or broader impact was not.
If the program requires CVSS, the version and vector should be supplied
based on the actual ID acquisition conditions and data sensitivity.
## Suggested Remediation
Enforce server-side object-level authorization on every order read.
Verify that the authenticated user is authorized to access the specific
order before returning any order data.
Do not rely solely on hiding orders in the UI, requiring login or making
order IDs difficult to guess. After remediation, verify with two regular
accounts that authorized access still works and unauthorized cross-account
requests are rejected.
十八、常見失敗寫法與提交前檢查
| 寫法 | 問題 | 改法 |
|---|---|---|
There is XSS |
看不出位置與觸發條件 | 補上功能、參數、觸發方式與結果 |
| 只有截圖或影片 | 難以照著操作或複製請求 | 補上文字步驟與必要請求 |
Critical vulnerability |
沒有評估依據 | 說明權限、互動、資料與影響範圍 |
Full account takeover |
證據沒有支持帳號接管 | 改成已完成的操作與結果 |
| 貼整包 Burp history | 太多無關請求 | 留下重現與驗證必要的內容 |
| 長篇介紹 OWASP | 看不到目標系統的問題 | 聚焦這次觀察到的行為 |
| 省略帳號切換 | 可能混用工作階段 | 明確標示每個請求使用誰的憑證 |
| 沒寫 ID 取得條件 | 看不出利用限制 | 區分測試時取得方式與真實攻擊條件 |
| 複製 AI 產生的 PoC | 可能改錯或沒有驗證 | 對照測試紀錄，重新跑過必要步驟 |
HackerOne 提醒避免模糊描述、缺少影響與無關資訊；Intigriti 和 YesWeHack 也提醒不要提交未驗證的 AI 內容。[1][11][12]
提交前檢查：
- 目標在允許測試的範圍內。
- 操作符合專案規則。
- 問題仍可重現；若為間歇性問題，已交代成功條件、次數或頻率。
- 標題包含漏洞、位置與已驗證影響。
- Summary 能快速說清楚問題。
- 帳號角色、資料準備與前置條件完整。
- 每個請求使用誰的憑證都很清楚。
- Endpoint、參數位置與替換方式明確。
- PoC 能驗證描述的問題，不只是程式可以執行。
- 回應內容與 Impact 的主張一致。
- 已驗證結果與推測分開。
- 無法安全驗證的影響已交代限制。
- Severity 依規則評估，沒有套用固定等級。
- Token、Cookie、密碼與個資已適當遮蔽。
- 遮蔽後的內容仍足以理解與重現。
- 附件實際存在，有寫用途，並符合分享規則。
- 語言、Markdown、編號與程式碼區塊正常。
- 沒有留下範本提示或未確認的 AI 主張。
十九、不同平台關注的重點
| 來源 | 報告重點 |
|---|---|
| HackerOne | 標題、步驟、預期與實際行為、影響、證據與精簡格式。[1] |
| Bugcrowd | 目標、漏洞分類、位置、重現、PoC 與實際影響。[3][4] |
| Intigriti | 英文優先、完整文字說明、端點、影響與補充附件。[5][6] |
| 漏洞描述、前置條件、影響分析、PoC、目標資訊、輸出與後續溝通。[7] | |
| Microsoft | 受影響元件、環境、可靠精簡的 PoC 與正確分析。[8][9] |
| Dropbox | 2015 年指南強調驗證、方法、重現與影響，曾建議使用母語。[10] |
| YesWeHack | 可驗證發現，避免憑空補寫、誇大影響與理論性主張。[11] |
Google and Alphabet VRP 的官方規則列出 0.8x、1x、1.2x 的報告品質係數；Google 官方 Cloud VRP 規則原始文件也列有相同係數。[7][14]
品質係數不是嚴重度分數，也不是所有 Google 獎勵計畫共用的保證。適用規則與最終獎金由相關計畫與評審決定。Google 的框架公告曾提到，低品質係數未來可能調整，因此不要把數字寫成永久規則。[15]
寫完之後，再問自己三個問題：
- 對方能照著重現嗎？
- 結果能支持我寫的安全影響嗎？
- 哪些部分還只是推測，我有說清楚嗎？
讓一個沒參與測試的人，能依照步驟與證據得到相同的結論，就是報告最重要的工作。
官方參考資料
- HackerOne：Quality Reports
- HackerOne：Severity
- Bugcrowd：Reporting a Bug
- Bugcrowd：Vulnerability Rating Taxonomy 官方儲存庫
- Intigriti：How to write and submit a good report
- Intigriti：How to write your submission’s Impact
- Google and Alphabet VRP Rules
- Microsoft：Example Report Submissions to the MSRC
- Microsoft：FAQs — Report an issue and submission guidelines
- Dropbox：Bug Bounty Program Best Practices（2015-08-31）
- YesWeHack：Write triager-grade Bug Bounty reports with Claude Code（2026-08-25）
- Intigriti：How to use AI for improved vulnerability report writing
- RFC 9110：HTTP Semantics，§15.5.4 與 §15.5.5
- Google 官方 Cloud VRP 規則原始文件：Report quality
- Google：Updated Report Quality Framework
