使用者在畫面上只能選自己的筆記，不代表伺服器收到的筆記 ID 一定屬於他。 理解資安問題的起點，是分清楚誰能控制資料，以及哪個元件有權決定是否接受它。
查證日期：2026-11-02。本文依 OWASP 威脅建模與 MITRE CWE 的定義整理；網頁持續更新。 只做文件查證，未架設或測試服務。以下筆記服務與政策是本站自創例子。
邊界來自控制權與信任程度
信任邊界（trust boundary）是資料在不同信任程度的區域之間移動的位置。 同一個網路或同一家公司內的元件，也可能有不同控制權；不能只用「內網」判定資料可信。 把未驗證資料混入已信任資料，會讓後續處理誤用它的權威性。 參考 MITRE CWE-501：Trust Boundary Violation。
假設有一個私人筆記服務，只有擁有者可以讀寫自己的筆記：
使用者控制的瀏覽器
│ HTTPS 請求：Cookie、筆記 ID、文字
▼
應用伺服器：驗證 Session、判斷權限、處理輸入
│ 使用受限服務帳號執行查詢
▼
資料庫：保存筆記、檢查約束與交易
瀏覽器傳來的 owner_id 不能直接成為擁有權證明；伺服器要由驗證後的主體與可信任的歸屬資料判斷。
資料庫中存放的筆記文字，也可能原本由其他使用者輸入；讀出來時不能因此當成可執行 HTML。
這是對上述案例的邊界分析，分別連到存取控制與 XSS。
先說清楚要保護什麼
資產不只有密碼。這個例子的保護目標包括：
| 目標 | 例子 | 失敗的可觀察結果 |
|---|---|---|
| 機密性 | 私人筆記只給擁有者 | 乙讀到甲的筆記文字 |
| 完整性 | 只有擁有者能修改 | 乙修改了甲的內容 |
| 可用性 | 合法讀寫能在可接受時間內完成 | 昂貴請求耗盡資源，其他人無法使用 |
實際可接受時間、資料敏感程度與風險排序，必須由具體系統決定；這裡沒有量測或承諾服務指標。 HTTP 成功回應只反映一次互動結果，也不能代替這些保護目標。
把擔心變成能檢查的情境
威脅建模是理解系統、找出可能失敗的方式、決定回應並驗證的反覆過程。 它應隨資料流與功能改變而更新，而不是完成一次表格就永久有效。 參考 OWASP Threat Modeling：Overview 與 System Modeling。
對筆記服務，可以先記下這些具體推演：
| 情境 | 接受判斷的位置 | 應有結果 |
|---|---|---|
| 乙把請求中的筆記 ID 換成甲的 ID | 應用的資源權限邊界 | 拒絕，且不回傳甲的筆記 |
| 筆記文字含看起來像標記的內容 | 瀏覽器輸出邊界 | 以文字顯示，除非有明確且受控的富文字政策 |
| 背景匯出工作讀取筆記 | 工作執行入口與資料讀取邊界 | 仍遵守該工作的身分與授權範圍 |
這些是案例推演，尚非已測試結果。好的驗證要觀察資料是否外洩或被修改，不能只看有沒有顯示錯誤頁。 測試的共同方法見〈API 測試〉。
每一層的保護有其範圍
HTTPS 保護傳輸中的資料，無法自行判斷筆記屬於誰。 參數化查詢保護 SQL 的語法邊界，無法保證呼叫者可讀取查到的資料。 登入確認身分，資源權限仍要另行判斷。這些分別處理不同失敗原因，不是可相互替換的開關。 相關機制見登入與 Session、SQL Injection與存取控制。
這一層理解也能幫助區分責任：資料庫外鍵保護資料關係，應用政策保護誰能使用資料。 增加一層防護時，先說明它在哪個邊界阻止什麼，再檢查其他入口是否仍能繞過。
相關文件
- Web 應用資安索引：依資料流選擇後續主題。
- 介面、契約與責任：辨認提供者與使用者的承諾。
- 關聯式資料庫索引：區分資料約束、交易與應用授權。