Handoff Security / 企業安全
安全報告示例：由問題到修補行動
以虛構預約例子，展示如何向負責人解釋問題並交給開發人員處理。
這是示例，不是客戶案例
以下使用合成資料，不代表真實客戶項目，也不表示你的網站存在相同問題。
如何閱讀報告？
先閱讀負責人摘要，再看約定範圍、證據、業務影響及修補建議。問題說明應指出哪項存取界線失效，以及開發人員如何驗證修補。
複測代表甚麼？
複測只在約定期限及工時內檢查原報告問題，不是對整個應用程式的認證，也不涵蓋之後所有改動。
預約網站例子：客戶看到別人的預約
這個虛構網站未有核對預約擁有人，已登入客戶因此可查看另一位客戶的預約。
- 有甚麼影響
- 私人預約資料可能外洩。
- 需要處理甚麼
- 推出此功能前，應優先檢查查看權限。
- 由誰跟進
- 負責人訂定優先次序，開發人員按 Handoff 的證據及建議修補存取檢查。
開發人員技術詳情
01 / 範圍及覆蓋
例子的範圍：一個虛構預約應用程式；兩個流程（查看及修改預約）、兩種角色（客戶、管理員）及兩個端點（GET /bookings/{id}、PATCH /bookings/{id}）。使用兩個合成客戶帳戶及一個管理員帳戶。覆蓋紀錄亦包括未確認問題的檢查；結論不涵蓋未測部分。
02 / DEMO-01 · 未檢查預約擁有權
受影響功能：透過 GET /bookings/{id} 查看預約。此例的優先程度：高，因一般客戶帳戶毋須另一位客戶同意便可讀取其私人預約。實際嚴重程度須按已驗證的存取及外露資料判斷。
03 / 合成重現步驟及證據
- 以合成客戶 A 登入，確認 DEMO-A 屬於 A，DEMO-B 屬於合成客戶 B。
- 使用 A 的同一登入狀態，先請求 GET /bookings/DEMO-A，再請求 GET /bookings/DEMO-B。
- 例子中的結果：兩次均回傳 200；第二次包含 {"id":"DEMO-B","owner":"customer-B","service":"Demo appointment"}。預期應拒絕存取，不回傳預約資料。
04 / 業務影響
例子中可讀取另一位客戶的預約內容。如包括姓名或聯絡資料，影響會更大；本合成證據未包含這些欄位，亦不推斷所有紀錄均可存取。
05 / 開發人員修補建議
每次讀取及修改預約時，伺服器須按已登入身分、紀錄擁有者及明確授權的角色判斷權限；未獲授權時先拒絕存取，才處理資料回傳。單靠難以猜測的紀錄編號並不足夠。加入自己紀錄、其他客戶及管理員存取的回歸檢查，由你的開發人員修改程式。
06 / 複測紀錄示例
DEMO-01 · 假設開發人員修補後的複測例子：A 請求 DEMO-B 時回傳 403，沒有預約資料；A 仍可讀取 DEMO-A。狀態：原有重現方式在已測條件下被阻止。這並非新一輪評估，亦不證明所有權限問題已修好。
07 / 限制及沒有確認漏洞的報告
本例子並非完整評估。未測端點、第三方平台、阻斷服務及源碼審計不包括在內。真實報告即使沒有確認漏洞，仍會記錄約定範圍、檢查、結果及限制；沒有確認漏洞不代表系統完全安全。