論文“信息的保護計算機系統”，由杰羅姆Saltzer和邁克爾·施羅德，提出8個的設計原則，同樣適用于RESTful-API。

1. 最小權限：實體應該只具有所需的權限集來執行授權的操作，而不再執行。可以根據需要添加權限，并在不再使用時撤消。
2. 失敗保護默認值：用戶對系統中任何資源的默認訪問級別應被“拒絕”，除非他們已明確授予“許可”。
3. 機制經濟：設計應盡可能簡單。所有組件接口和它們之間的交互應該足夠簡單易懂。
4. 完全中介：系統應驗證其所有資源的訪問權限，以確保它們被允許且不應依賴緩存的權限矩陣。如果正在撤消對給定資源的訪問級別，但未在權限矩陣中反映，則會違反安全性。
5. 開放式設計：該原則強調了以開放的方式構建系統的重要性 – 沒有秘密的機密算法。
6. 權限分離：授予實體權限不應完全基于單一條件，基于資源類型的條件組合更好。
7. 最不常見的機制：它涉及在不同組件之間共享狀態的風險。如果可以破壞共享狀態，則可以破壞依賴于它的所有其他組件。
8. 心理可接受性：它指出安全機制不應使資源更難以訪問，而不是安全機制不存在。簡而言之，安全性不應該使用戶體驗變得更糟。

API描述規范自帶的安全要求

REST API 安全

REST（表述性狀態轉移）API 通常使用 HTTP，并依賴 HTTPS 等機制進行加密、OAuth 進行授權以及 JWT（JSON Web 令牌）進行安全令牌交換。它們的無狀態性質意味著應用程序必須單獨驗證每個請求，從而增強安全性。REST 在選擇安全協議方面的靈活性允許 更容易 但需要仔細配置以防止漏洞。

SOAP API 安全性

另一方面，SOAP（簡單對象訪問協議）API 在其協議中內置了 WS-Security 安全性。SOAP 包括消息完整性、機密性和身份驗證的標準。 SOAP 可以使用安全套接字層 (SSL) 或傳輸層安全性 (TLS) 用于加密. 盡管如此，其消息級安全性確保即使傳輸層受到威脅，消息仍保持安全。SOAP 的嚴格標準使其本質上更安全，但實施和維護也更復雜。

## API安全最佳實踐

REST是一個架構約定，在該約定中，缺少安全特性相關的內容。經過這些年的發展，市場總結了一些REST 的 API安全最佳實踐，有些已經默認實現在網關產品、有些需要開發者自己負責，供大家參考：

1、始終強制使用TLS加密，網關產品可提供
與其他類型的敏感 HTTP 流量一樣，將 TLS 用于 RESTful API 有助于確保對 API 用戶和 API 端點之間的所有通信進行加密。這對于 REST API 安全性和 Web 應用程序安全性同樣重要，因為生成的 HTTP 流量包含敏感的身份驗證詳細信息，如密碼、API 密鑰或令牌。

2、API秘鑰，部分網關產品可提供
API密鑰可用于請求方身份標識，用API秘鑰加密請求內容及響應內容。常用方式有’對稱秘鑰、非對稱秘鑰‘等，避免使用Appcode模式。B2B模式的API網關必用API秘鑰；自有APP到API網關時，常用非對稱秘鑰模式+其它手段來標識‘APP’，避免套殼等風險。

3、身份認證 ，三方產品可提供
認證是指驗證用戶身份的過程，常見的認證方式包括 HTTP Basic 認證、SAML、Token 認證、OAuth 2.0 等。

4、授權模型，三方產品可提供
授權是指驗證用戶是否有訪問特定資源的權限。通過API訪問內部數據和系統的組織必須引入和測試控制來管理這種訪問:何人、內容和時間，以及對數據訪問、創建、更新和刪除的檢查——零信任安全模型。

5、不在URL中包含敏感信息，做URL過濾，開發者負責
一個常見的 REST API 設計缺陷是在 URL 中包含敏感信息，包括用戶憑據、密鑰或令牌。

6、嚴格定義允許的RESTful API請求和響應，開發者負責
— 錯誤處理
— 應始終考慮對輸入進行驗證
— 嚴格管控 REST API 可提供的響應類型。例如，響應應限制為明確允許的內容類型，如 GET、PUT 和 POST。

7、重要ID不透明處理，開發者負責
在系統一些敏感功能上，比如，/user/1123 可獲取 id=1123 用戶的信息，為了防止字典遍歷攻擊，可對 id 進行 url62 或者 uuid 處理，這樣處理的 id 是唯一的，并且還是字符安全的。

8、速率限制，網關產品可提供
設計良好的API還可以應用速率限制和地理速度檢查，以及作為地理圍欄和I/O內容驗證和消毒等策略的執行點。

9、實施持續API發現功能，避免產生新的安全漏洞，三方產品可提供
分析API日志以獲取 API 活動的證據，這將有助于確保您的安全團隊了解企業中正在使用的所有 API。

常用身份驗證模型

RESTful應用程序依賴于API生態系統的底層安全性，而不是在REST架構風格中包含安全性。除了通過HTTPS協議保護RESTful API調用之外，還應使用基于會話的身份驗證。目前，大多數RESTful應用程序利用了OAuth 2.0和Open ID Connect（OIDC）協議。

SAML

安全評估標記語言（SAML）最初由大學設計，以允許其他大學的學生訪問圖書館。基于XML和SOAP是原始的聯合身份系統。在2000年代初期，當互聯網瀏覽器成為主要客戶的時候，SAML被推出。

OAuth 2

OAuth 2創建于2006年，是認證協議的開放標準，通過HTTP提供授權工作流程，并授權設備，服務器，應用程序和API以及訪問令牌而不是憑據。 OAuth從Facebook，Google，Microsoft和Twitter的使用中獲得了普及，他們允許使用他們的帳戶與第三方應用程序或網站共享。

開放ID連接（OIDC）

開放式ID連接（OIDC）擴展了OAuth 2，并將用戶信息（身份層）作為請求的一部分。考慮到SAML的現代版本，OIDC允許一系列客戶端，包括基于Web的移動設備和使用JavaScript的客戶端。

JSON網頁令牌（JWT）

JSON Web Token（JWT）是一種用于創建訪問令牌的開放標準，用于聲明一些聲明。使用[[json|JSON]]編寫的令牌旨在緊湊 – 專注于使用Web瀏覽器，單點登錄（SSO）上下文。雖然不是身份提供商或服務提供商，但JWT用于在身份和服務提供商之間傳遞身份驗證的用戶身份。

RAML

RESTful API建模語言（RAML）是一種旨在描述RESTful API的語言。 RAML是用YAML人類可讀的數據串行化語言編寫的。 RAML的努力首先在2013年提出，并獲得了諸如MuleSoft，AngularJS，Intuit，Box，PayPal，可編程Web和API Web Science，Kin Lane，SOA Software和Cisco等技術領導者的支持。 RAML的目標是提供所有必要的信息來描述RESTful API，從而提供一種更簡單的設計API的方法。

參考資料

REST API 面臨的 7 大安全威脅REST API 安全要點
API 安全性實踐API安全成熟度模型
應用程序接口（API）安全的入門指南 ，大量基礎概念，可以作為清單來用
Web應用風險點有哪些？

擴展閱讀

• OWASP 風險評級方法
• 關于威脅/風險建模的文章
• ISO 31000：風險管理標準
• ISO 27001：信息安全管理體系
• NIST 網絡框架（美國）
• ASD 戰略緩解措施 (AU)
• NIST CVSS 3.0
• Microsoft 威脅建模工具