[TOC] >[參考](http://restful.p2hp.com/learn/security-essentials) ## 安全設計原則 最小權限 * 實體應該只具有所需的權限集來執行授權的操作，而不再執行。可以根據需要添加權限，并在不再使用時撤消。 失敗保護默認值 * 用戶對系統中任何資源的默認訪問級別應被“拒絕”，除非他們已明確授予“許可”。 機制經濟 * 設計應盡可能簡單。所有組件接口和它們之間的交互應該足夠簡單易懂。 完全中介 * 系統應驗證其所有資源的訪問權限，以確保它們被允許且不應依賴緩存的權限矩陣。如果正在撤消對給定資源的訪問級別，但未在權限矩陣中反映，則會違反安全性。 開放式設計 * 該原則強調了以開放的方式構建系統的重要性 - 沒有秘密的機密算法。 權限分離 * 授予實體權限不應完全基于單一條件，基于資源類型的條件組合更好。 最不常見的機制 * 它涉及在不同組件之間共享狀態的風險。如果可以破壞共享狀態，則可以破壞依賴于它的所有其他組件。 心理可接受性 * 它指出安全機制不應使資源更難以訪問，而不是安全機制不存在。簡而言之，安全性不應該使用戶體驗變得更糟。 ## 最佳實踐 1. 把事情簡單化 2. 始終使用HTTPS 通過始終使用SSL，可以將身份驗證憑據簡化為隨機生成的訪問令牌，該令牌在HTTP Basic Auth的用戶名字段中提供。它使用起來相對簡單，您可以免費獲得許多安全功能。 - 如果使用HTTP 2來提高性能 - 您甚至可以通過單個連接發送多個請求，這樣就可以避免以后的請求產生完整的TCP和SSL握手開銷。 3. 使用密碼哈希 4. 永遠不要公開URL的信息 用戶名，密碼，會話令牌和API密鑰不應出現在URL中，因為這可以在Web服務器日志中捕獲，這使它們很容易被利用。 如`https://api.domain.com/user-management/users/{id}/someAction?apiKey=abcd123456789 /` 5. 考慮一下OAuth 雖然[基本身份驗證](https://en.wikipedia.org/wiki/Basic_access_authentication)對于大多數API都足夠好，但如果正確實現，它也是安全的 - 但您也可能想要考慮[OAuth](https://tools.ietf.org/html/rfc6749)。OAuth 2.0授權框架允許第三方應用程序通過編排資源所有者和HTTP服務之間的批準交互，或者通過允許第三方應用程序來代表資源所有者獲得對HTTP服務的有限訪問權限以自己的名義獲取訪問權限。 6. 考慮在請求中添加時間戳 與其他請求參數一起，您可以在API請求中將請求時間戳添加為HTTP自定義標頭。服務器會將當前時間戳與請求時間戳進行比較，并且只有在合理的時間范圍內（可能是1-2分鐘）才接受請求。 這將阻止那些試圖在不更改此時間戳的情況下強行執行系統的人進行非常基本的重播攻擊。 7. 輸入參數驗證 在到達應用程序邏輯之前，在第一步驗證請求參數。如果驗證失敗，請進行強有力的驗證檢查并立即拒絕請求。在API響應中，發送相關的錯誤消息和正確輸入格式的示例以改善用戶體驗。