今天，令人印象深刻的是有 64% 的企業正在創建用于內部或外部用例的 API。雖然有四分之一的受訪者現在根本沒有創建 API，但 40% 的受訪者都利用了內部和外部用例中的 API。
目前，大多數利用 API 的企業都依賴他們的開發人員來編寫和管理這些 API。盡管 33% 的受訪者使用專門的技術來管理他們的 API，但 90% 的受訪者依靠他們的開發團隊或外部資源從零開始編寫 API。
越來越多的新云應用程序之間的集成編碼工作已經讓企業不堪重負，因此企業對開發人員提出了更高的要求，要求他們為企業創建和管理 API。
在設計、測試和部署 REST API 的任何時候，安全問題都是必須考慮的一個重要方面。隨著 REST API 的飛速發展，在設計和開發 API 的過程中，安全級別往往被低估。如今，敏感數據（無論是組織信息還是個人信息）的安全性是困擾開發人員的一個重要因素。REST API 也不例外，它是重要系統的一部分，需要防范安全威脅和漏洞。
根據 2018 年 Postman 社區報告調查，與前一年相比，越來越多的開發人員開始關注 REST API 的安全性，并對其抱有更高的信心：
在本篇文章中，我將介紹當今 IT 世界中的 7 大 REST API 安全威脅，以引起大家的注意，并幫助大家了解能夠影響 REST API 性能的安全威脅。
REST 框架中的分層轉換序列意味著鏈中的一個薄弱環節就可能會使我們的應用程序變脆弱。
在注入攻擊中，危險代碼被嵌入到一個不安全的軟件程序中，以發起攻擊，其中最著名的是 SQL 注入和跨站點腳本攻擊。實際上，這種暴露可以通過將不受信任的數據作為查詢或命令的一部分傳輸到 API 中來操作。該輸入隨后由解釋器實現，這可能會導致攻擊者獲取未經授權的信息訪問權限或造成其他損害。
阻止或拒絕注入攻擊最有效方法是添加輸入驗證，以下是幾個最重要的準則：
驗證輸入：長度、范圍、格式及類型通過在 API 參數中使用強類型（如數字、布爾值、日期、時間或固定數據范圍）來實現隱式輸入參數校驗用正則表達式約束字符串的輸入定義適當的請求大小限制并使用 HTTP 響應狀態 413（請求實體太大）來拒絕超過該限制的請求
在拒絕服務（DoS）攻擊中，攻擊者在大多數情況下會推送大量消息，請求服務器或網絡建立由無效返回地址組成的請求。如果沒有采取適當的安全防范措施，這種攻擊能夠使 RESTful API 處于無法運行的狀態。最近，無論 API 是否公開，其他人（包括攻擊者）都可以訪問它。
隨著這些 API DoS 攻擊變得變得越來越普遍，并且隨著組織越來越多地依賴 API 來滿足其業務需求，安全專業人員應該開始積極計劃應對此類攻擊。即使禁用用于應用程序身份驗證的 API 密鑰（或訪問令牌），也可以通過標準瀏覽器請求輕松地重新獲取密鑰。
因此，使當前訪問令牌失效不是一個長期的解決方案。如果 DoS 攻擊可以追溯到某個特定的 IP 地址，那么將該 IP 地址列入黑名單也不是長久之計，因為攻擊者可以很容易地獲取一個新的 IP 地址。
這就是為什么需要多種訪問控制方法的原因。對于非敏感信息，使用 API 密鑰可能就足夠了。然而，為更好地防止 DoS 攻擊，需要使用 HTTPS 和更健壯的身份驗證機制，包括 OAuth 、相互（雙向）TLS（傳輸層安全性）身份驗證或 SAML （安全斷言標記語言）令牌。
為防止可能會導致 DDoS 攻擊或其他 API 服務濫用的大量 API 請求，請在給定時間間隔內對每個 API 的請求數量施加限制（也稱為峰值阻止）。當超過此速率時，至少暫時阻止來自該 API 密鑰的訪問，并返回 429（請求過多）HTTP 錯誤碼。
如果我們開始構建新的 REST API 了，請先檢查下 Web 服務是否具有一些面向安全性的特性。
這些特殊的問題可能使攻擊者繞過或控制 Web 程序使用的身份驗證方法。身份驗證丟失或不足可能會導致攻擊，從而破壞 JSON Web 令牌、API 密鑰、密碼等。
攻擊的目的通常是控制多個帳戶，更不用說攻擊者獲得與被攻擊用戶同等的權限。只有經過身份驗證的用戶才可以訪問這些 API。
使用 OpenID/OAuth 令牌、PKI 和 API 密鑰可以很好地滿足 API 授權和身份驗證需求。最好不要通過未經綁定的連接發送憑據，也不要在 Web URL 中顯示會話 ID。
由于在傳輸中或靜態時缺乏加密而導致的敏感數據暴露可能會導致攻擊。當應用程序無法正確保護敏感數據時，就會發生敏感數據泄漏。這些信息可能是私人健康信息、信用卡信息、會話令牌、密碼等，而且包含越多的信息越容易受到攻擊。敏感數據需要很高的安全性，除了在與瀏覽器進行交換時采取非常規的安全做法外，還包括靜態或傳輸中的加密。
為了避免敏感數據泄露，必須使用 SSL。
今天，我們可以通過 Let’s Encrypt 得到一個免費證書。SSL 和 TLS 在消除基本 API 漏洞方面經驗豐富，幾乎不費吹灰之力。
要想獲得一份有關實施效果的出色報告，請使用 Qualys SSL 服務測試，測試你的 URL。這是我們的測試結果：
訪問控制，在某些情況下稱為授權，是一個 Web 軟件允許某些人而不是所有人訪問它的功能和內容的方式。缺少訪問控制或訪問控制不足可能會使攻擊者可以控制其他用戶賬戶、變更訪問權限、變更數據等。
當開發人員未能正確地配置操作級的可訪問性時，公司應用程序訪問就容易受到攻擊，從而導致訪問漏洞。拒絕訪問是破壞訪問控制的最常見后果，而利用訪問控制是攻擊者的主要手段。
由于某些框架中缺少訪問控制，因此可以通過手動或自動化的方式來檢測訪問控制。如果在可靠的無服務器或服務器端 API 中實現了訪問控制，則訪問控制通常是有效的，因為攻擊者將無法更改訪問控制元數據。
這是一種基于操作客戶端和服務器之間交換的參數來修改應用程序數據（例如，用戶憑據和權限、產品價格和數量等）的攻擊。通常，這些信息存儲在 cookie、隱藏表單字段或 URL 查詢字符串中，用于增強應用程序的功能和控制。
當有害的網站、程序、即時消息、博客或電子郵件使用戶的 Internet 瀏覽器在授權的網站上執行不必要的操作時，就會發生這種情況。它允許攻擊者在被攻擊用戶不知情的情況下，使用目標的 Web 瀏覽器使目標系統執行某個功能，直到未經授權的事務被執行為止。
攻擊能否成功取決于完整性和邏輯驗證機制的錯誤，利用該機制可能還會導致其他攻擊，包括 XSS、SQL 注入、文件包含和路徑泄漏等攻擊。
我們應該仔細地校驗接收到的 URL 參數，以確保該數據能代表來自用戶的有效請求。無效請求可用于直接攻擊 API 或攻擊 API 背后的應用程序和系統。將校驗器放在應用程序上，并嘗試對發送到 REST API 的請求使用 API 簽名。還可以為 API 創建自動化安全測試，以確保沒有參數篡改來影響我們的 REST API。
它是指攻擊者秘密地更改、攔截或中繼兩個交互系統之間的通信，并攔截它們之間傳遞的私有和機密數據。MITM 攻擊分為兩個階段：攔截和解密。
API 中缺少傳輸層安全性（Transport Layer Security，TLS）實際上等同于向黑客發出公開邀請。傳輸層加密是安全 API 中最基本的“必備條件”之一。除非使用 TLS，否則遭受普遍存在的“中間人”攻擊的風險仍然很高。在 API 中同時使用 SSL 和 TLS 很有必要，尤其是要使用公開 API時。
在開發 REST API 時，必須從一開始就注意安全性。可以考慮使用內置了許多安全特性的現有 API 框架。在 Rest Case 中，我們使用的是 SugoiJS API 框架，除測試和安全指導之外，我們還為其代碼庫做出了貢獻。通過這種方式，安全性被統一地內置，并且開發人員可以更專注于應用程序的邏輯。
在這之后，不要忘記分配資源來測試 API 的安全性。一定要測試本文中所提到的所有安全威脅。
原文鏈接：Top 7 REST API Security Threats