每個請求都必須在伺服器端驗證主體、動作與資源關係；不可只依賴隱藏按鈕、不可猜 ID 或前端角色。
身分驗證不等於有權限
登入只能證明目前是某個帳號，授權則決定這個帳號能對哪個資源做什麼。IDOR（不安全的直接物件參照）常發生在網址或 API 帶有訂單、檔案、使用者編號，而伺服器只確認「已登入」，沒有確認資源是否屬於該使用者或租戶。
隱藏按鈕、把 ID 換成 UUID、或在前端寫角色判斷都不能取代伺服器授權。攻擊者可以直接修改請求。
每個入口都做同一套判斷
授權邏輯應集中且預設拒絕：先確認主體、目標資源、動作、租戶與必要條件，再執行讀取或修改。列表、單筆、匯出、下載、批次、搜尋與舊版 API 都要使用相同規則。
資料庫查詢最好直接帶入擁有者或租戶條件，例如同時以資源 ID 與 tenant ID 查找，而不是先查出資源再靠前端決定是否顯示。
角色只是起點
角色型控制適合定義一般能力，例如客服可讀工單、財務可看付款；但還要加入資源關係與狀態，例如客服只能處理所屬組織的工單，已結案紀錄不可任意修改。高權限操作應要求更強驗證與完整稽核。
不要使用可由客戶端修改的角色 Cookie 或表單欄位作為信任來源。權限狀態應由伺服器端資料或經驗證的安全宣告取得。
避免過度暴露
API 回應只傳送目前畫面真正需要的欄位，避免先回傳完整資料再由前端隱藏。錯誤訊息不應讓未授權者分辨「資源存在但你不能看」與「不存在」，除非業務明確需要。
下載網址若為公開分享，使用高熵、可到期、可撤銷的 Token；若內容敏感，仍需登入與伺服器授權，不把長期可用的物件儲存網址直接交給任何人。
管理後台與服務帳號
管理功能使用獨立權限與最小範圍，不讓一般帳號只靠修改路徑進入。服務帳號與 API 金鑰也要限制可用動作、來源與有效期，不能共享一把全能金鑰。
權限變更、批次匯出、刪除、角色指派與跨租戶存取都應留下不可由一般使用者修改的稽核事件，並對異常量與失敗嘗試告警。
用權限矩陣測試
列出角色 × 動作 × 資源關係的矩陣，為允許與拒絕情境都建立自動測試。至少使用兩個不同帳號與兩個租戶，交換資源 ID、檔案 ID、父層 ID 與批次參數。
修補後不要只測原始網址；檢查同一資源的 API、行動版、匯出與歷史版本。授權漏洞往往是某個較少使用的入口漏掉共用檢查。