本文中討論了API安全性和採用安全措施的重要性，如身份驗證，API密鑰，訪問控制和輸入驗證。
API設計的第一步是撰寫接口文檔
根據TechTarget（海外IT專業媒體）的定義，RESTful API是一個應用程序接口，它使用HTTP請求來獲取GET，PUT，POST和DELETE等數據。從技術層面上看，RESTful API（也稱爲RESTful Web服務）是一種基於代表性狀態轉移（REST）技術，這是一種通常用於Web服務開發的架構風格和通信方法。
但隨着 RESTful API 應用範圍的爆炸性擴大，安全性越來越成爲API架構設計中最容易被忽視的部分。
爲什麼API安全性很重要？
在設計和部署RESTful API時，有以下三個核心原因可以解釋爲什麼安全性應該是一個很重要的考慮因素。
1.數據保護
RESTful API是一種向外界傳輸價值的服務方式。因此，保護通過RESTful方式提供的數據始終應該是屬於高優先級。
2.DOS攻擊
如果不採取正確的安全措施，（DOS）攻擊可以使RESTful API進入非功能狀態。考慮到很多基礎的RESTful API是開放給所有人使用的情況，通過這種類似開源的方式有助於它更好推廣給市場，讓更多人投入使用，但同時意味着如果有人選擇對API執行DOS攻擊時，它也可能導致災難性的結果。
3.商業影響
如今有越來多的服務平臺，提供着影響衣食住行的各種信息，從飛機航班時刻表到高鐵餘票查詢，甚至只是超市裏日常用品，都能給你提供價格、數量、時間等諸多信息，讓你足不出戶，買到最合心意的商品。在這樣的大趨勢下，這種利用API數據來獲取更多信息，再提供給你的聚合服務平臺將會越來越多。於是通過RESTful API傳輸的信息會被頻繁調用，而其中的個人信息很容易被泄露。
保障安全採用的措施
以下介紹一些RESTful API通用設計中的關鍵概念。
1.會話管理和認證
除了使用TLS / HTTPS之外，最重要的RESTful API安全級別是以會話管理和身份驗證爲中心的。在本文討論中重點將放在API密鑰，OpenID Connect / OAuth2 / SAML和會話狀態事項上。
2.API密鑰
API密鑰的概念是爲使用者提供了作爲其HTTP請求的一部分的唯一字符串（密鑰）。雖然不是一個完整的安全解決方案，但與匿名使用相比，使用API密鑰可以更清楚地瞭解誰在使用API。
API密鑰也可用於提供附加服務。例如，對於RESTfulAPI，附加的服務可以選擇使用不同的級別。以一般、高、最高三個等級爲例，在“一般”的級別，用戶可以自由訪問，但只能訪問一組有限的數據。假如要訪問更多組的數據，那就必須支付費用才能訪問“高”的級別，以此類推，不受限制的訪問所有的數據則要支付“最高”等級的費用，通過提供不同API密鑰的方式，提供額外的服務。
使用API密鑰的最常用的方式是將它們包含在請求頭中。
例如，當調用某個小部件的頭部時，67A73DD1BD1D90210BA的API設置爲HTTP頭部中的X-API-KEY鍵/值對：
curl-H“X-API-鍵：67A73DD1BD1D90210BA”
API密鑰的另一個常見用法是將該密鑰包含在URI中：
https://www.example.com/v1/wi... 67a73dde1bdd1d90210ba
但這種方法的問題在於，API密鑰在瀏覽器歷史記錄和對應服務器的日誌中都會顯示出來，意味着向所有有權訪問這些數據的人公開唯一密鑰。
3.OpenID Connect，OAuth2和SAML
OpenID Connect，OAuth2和SAML使用HTTP協議作爲傳輸，用於安全目的。身份驗證提供個人的驗證，同時授權執行或撤消訪問的任務。
從身份驗證角度來看，存在以下選項：
- OpenID Connect：可以利用現有的身份提供商（如Google或Facebook）獲取用於驗證用戶授權的令牌。
- OAuth2：可以通過授權執行僞認證（如下所述）。
- SAML：使用斷言、協議、綁定和配置文件來管理身份驗證，包括標識提供者，但不太適合移動應用程序驗證。
爲提供授權服務，採用以下策略：
- OAuth2：提供安全的委託訪問，通過允許第三方身份提供程序頒發令牌來代表用戶執行操作。由於OAuth2必須瞭解被委派的用戶，因此身份驗證是以僞方式實現的（如上所述）。
- SAML：對可信服務執行斷言，包括提供授權的令牌。
4.會話狀態事項
RESTful API端點應始終保持無狀態會話狀態，這意味着會話的所有內容都必須保存在客戶端。來自客戶端的每個請求都必須包含服務器理解請求所必需的所有信息。爲了簡化流程，包括API令牌以及會話令牌，作爲每個業務中都需要的一部分。
5.訪問控制
如上所述，對RESTful服務的授權可以將安全性引入到所提供的端點中，以便對那些可以向API發出HTTP刪除請求的人有限制。
在下面的簡單Java示例中，只有Admin和Manager角色（即組）的成員可以執行刪除所有用戶的DELETE請求，但是所有用戶都可以執行GET請求以獲取用戶列表：
6.速率限制
如上所述，API密鑰是判斷RESTful API的使用者身份級別一種很有用的策略。除了提供等級識別外，使用API密鑰的另一個好處是能夠限制API的使用，例子像Tibco Mashery、MuleSoft和Dell Boomi等API管理解決方案允許限制API請求，利用API密鑰實現此功能。因此，試圖執行DoS攻擊（有意或無意）的時候將會達到一個設定的閾值，到達閾值後後續所有的請求都將被拒絕。
7.輸入驗證和HTTP返回代碼
在保護RESTful API時，應始終考慮對輸入進行驗證。例如，如果用戶試圖發佈與地址相關的JSON數據集合，則RESTful端點內的服務應驗證數據並使用HTTP返回代碼來反映正確的狀態。在下面簡化的Java示例中，就是調用一個非常基本的AdvSersService來驗證和保存地址：
在上面的示例中，使用isValidAddress（）方法驗證newAddress對象（從JSON編組到Address Java對象）。如果地址無效，則向用戶返回HTTP 401（錯誤請求）代碼，文本顯示爲“提供的地址無效。” 如果認爲該地址有效，則convertAddress（）將執行必要的操作，然後將包含地址內容的JSON格式的字符串返回給用戶，以及一個HTTP 201（創建）返回代碼。
結論
保護RESTful API的安全應該始終處於API設計工作中最先被考慮的部分。如果不保護敏感數據，允許DOS攻擊以及不考慮使用RESTful API的影響，那麼即使它只是短暫的影響，相關的風險可能很容易使企業處於不利地位。
授權和身份驗證可以爲RESTful API提供必要的安全性，實現API密鑰策略可以有效的用最低成本保護RESTful API的安全。對輸入內容進行驗證始終應該是RESTful API的一部分，因爲無法保證API後續是否會進行任何必要的驗證，同時返回到客戶端的結果應該符合預設中HTTP返回代碼，而不僅僅只是狀態碼顯示的成功（200）或者錯誤（404）。
除了API的安全性需要被保護，時刻掌握API運行中的動態也是很重要的事情。最近發掘了一個新的工具：EOLINKER，他們本身是做API研發管理服務，因工作原因最近一直使用他們的另一個產品：API監控，最大的改變就是能隨時查看接口是否報錯，報錯時可以查看錯誤的地方，對比之前效率高了不少，對API管理、監控等方面有興趣的小夥伴自行了解下哦！https://www.eolinker.com
你使用過RESTful API嗎？又對RESTful API安全性有什麼看法？歡迎在下方留言一起討論。
原標題：RESTful API Security
作者：John Vester
參考原文地址：https://dzone.com/articles/re...