授權跟著物件走
假設 /reports/42 回傳報告。伺服器不能只檢查「已登入」，還要確認該使用者能讀報告 42。相同角色的不同使用者，可能只有權讀自己的物件；這是常見的水平存取邊界。
若 ID 很難猜，只是降低猜中的機率。識別碼可能從合法分享、紀錄或其他頁面被知道。真正的控制應在可信邊界，對每次請求驗證身分、資源及動作。
驗證拒絕，也驗證合法分享
建立兩名合成使用者與兩份合成報告。先驗證各自可讀自己的，再驗證不能讀對方的；若產品允許分享，另外列明分享關係、到期與撤銷。不要把所有存取都拒絕當成完整成功。
失敗時應回傳適當且一致的錯誤，避免暴露不必要的物件資訊。具體使用 403 或 404 取決於設計，但結果不能仍包含受保護的資料。
例子：同樣是 student，資料仍分開
虛構使用者 A 擁有報告 42，B 擁有報告 43。兩人都是 student。B 知道 42 的網址。
角色相同只能說明部分政策；還需要所有權或明確分享關係。若沒有分享，B 的讀取應被拒絕。
判斷：驗證規則可以是 owner==user 或有效分享授權，而非只看 role==student。
離線練習：四個存取案例
只填表格，不操作任何真實帳號或網址。
- 列出 A→42、A→43、B→42、B→43。
- 先在無分享條件填允許與拒絕。
- 再加入 A 明確分享 42 給 B 的情境，指出哪一格改變。
預期結果
無分享時只有 A→42 與 B→43 允許；有效分享後 B→42 可以依政策改為允許。
自行檢核
撤銷分享後，哪個案例必須重新變成拒絕？
結束與清理
保存矩陣；沒有帳號或分享權限需要回復。