API（應用程序編程接口）安全風險在過去兩年中發生了巨大變化。下面將討論一下當今最重要的 API 安全問題以及如何解決這些問題。

　　作為一名長期的OWASP成員和應用程序安全從業人員，我想與大家分享一下我的想法，關于新發布的OWASP Web App Top 10（應用安全風險Top 10）將會如何影響API security Top 10（API安全風險Top 10）的更新。上一輪API security Top 10發布于2019年12月。

　　最近更新了Web App Top 10（應用安全風險Top 10），以反映不斷變化的應用程序和威脅情況。

　　以目前的形式，API安全風險Top 10與2017年Web應用安全風險Top 10大致有60%的重疊。這在當時是有意義的，因為API的使用才剛剛開始激增，而且對于如何最好地滿足API的安全需求，確實需要指導。

　　自API安全風險Top 10發布以來，API的使用和相關的安全問題都發生了變化。即便如此，從API安全風險Top 10和新的 Web應用安全風險Top 10中可以得出許多相似之處：

　　在下一輪API安全風險Top 10列表中，我希望術語保持一致，盡管我不期望類似的定位，因為API和Web應用之間存在明顯的差異。我預計新的Web應用程序列表會有一些重疊，但會有一些特定于API的威脅，比如：

　　讓我們看看對未來列表的預測。

　　下一輪OWASP API安全風險Top 10預測

　　API:1 和API:2：識別和認證失敗以及訪問控制中斷

　　與API身份驗證和授權錯誤相關的安全事件幾乎與安全錯誤配置一樣常見，這證明了將其放在列表頂部的合理性（并對錯誤配置排名的第5位提出了質疑）。組織需要更加關注他們設計和實現API的方式，也許可以使用安全規范來監視缺少的端點身份驗證、授權和管理功能。

　　API:3加密失敗

　　加密失敗一直困擾著Web應用程序。在早期，開發人員拒絕進行可能需要用戶升級的更改。因此，將強加密作為應用程序（或API）要求是不受歡迎的——但現在不會了。強制升級以改善數據保護并可能防止信用違約成為常態。開發人員可能會失去一兩個客戶，但不會擔心因為泄露的數據交換和糟糕的加密而發布有關信用卡違規的消息。同樣，利用API的應用程序現在可以包含證書和強大的加密算法。

　　API:4缺乏資源和速率限制

　　此威脅在列表中排名更高，因為API使合法或惡意流量峰值更容易發生。今年我們看到針對API的惡意流量峰值增加了30倍。如果不應用速率限制，這將是一場災難。組織需要更加努力地對API實施速率限制，因為它不僅有助于抵御惡意攻擊，還有助于控制基礎設施成本超支。

　　API:5安全配置錯誤

　　安全配置錯誤的API是我們在客戶群中看到的常見錯誤。根據我們在新聞中看到的內容，這是許多組織的常見錯誤。意外的端點，或那些沒有身份驗證或授權標志的端點，只是我們看到的幾個錯誤示例。出現這種頻率的原因是，API安全性錯誤配置沒有被大多數組織檢測到。要想把這條從列表中刪除，組織需要了解和測試他們的 API 功能——不僅僅是滲透測試，而是真正的功能測試。

　　API:6不安全的設計

　　隨著“左移”和DevSecOps的廣泛采用，應用程序安全架構師的作用迅速發展。隨著API變得越來越基礎化，了解體系結構、特別是API每個部分的安全性至關重要。當應用程序在內部、外部或向第三方/從第三方使用或發送數據時，將訪問或移動該數據的所有實例都需要安全設計。這只是一個小例子，當需要體系結構時，還需要考慮登錄、會話管理、授權和其他方面。

　　API:7注入

　　注入在此列表中排名靠后，而在新的AppSec前十名中排名靠前，因為 Web應用程序是通過Web瀏覽器查看的，并且需要JavaScript來呈現部分頁面。這可能會導致跨站腳本攻擊 （XSS），隨后通常會針對后端數據庫進行SQL注入。API通常不需要瀏覽器，因此注入是可能的，但可能性較小。API注入通常只發生在某人對應用程序有深入了解并試圖打破另一種機制時。

　　API:8資產管理不當

　　API資產管理從一個良好的清單開始，該清單隨著元素的添加和刪除而更新。大多數組織都在為他們的應用程序清單而苦惱，很少有人準確了解他們擁有的 API數量及其所有相關組件。API可見性和資產管理應該是所有 API安全計劃的基石。

　　API:9日志記錄和監控不足

　　每當問到“發生了什么？”這一主要安全問題時，只能通過找出可用的日志來得出答案。沒有日志，就很難確定根本原因。日志記錄和監視成本低廉，易于實現，并且經常需要進行故障排除。我很想看到這一項在下一輪榜單中消失。

　　API:10數據完整性失敗

　　對于任何圍繞API中的數據完整性的事情來說，這最終有點籠統。這可能是第三方庫或其他存在缺陷的依賴項。這可能是持續集成和交付（CI/CD） 管道未確認源或添加以某種方式易受攻擊的源的問題。這些類型的故障越來越突出，但代碼完整性的概念變得越來越重要。我們有機會扭轉這一趨勢。

　　這個 API Top 10列表，我覺得在不久的將來會在官方OWASP列表修訂中反映出來。其中大部分來自處理被自動化對手攻擊的 API，以及那些希望在組織內站穩腳跟的 API。

　　相關鏈接：

　　OWASP（開放式Web應用程序安全項目- Open WebApplication Security Project）是一個開放社群、非盈利性組織，長期致力于協助政府或企業了解并改善網頁應用程式與網頁服務的安全性。近期其發布的OWASP Web App Top 10（應用程序安全風險Top 10）一文摘譯如下。

　　2021 年前 10 名發生了什么變化

　　有三個新類別，四個類別的命名和范圍發生了變化，并在 2021 年的前 10 名中進行了一些整合。我們在必要時更改了名稱，以關注根本原因。

　　A01:2021-失效的訪問控制從第五名上升到 Web 應用程序安全風險最嚴重的類別；提供的數據表明，平均3.81%的測試應用程序具有一個或多個通用弱點枚舉 （CWE）。映射到失效的訪問控制的34個CWE在應用程序中出現的次數比任何其他類別都多。

　　A02:2021-加密失敗上移一名至第二名，以前稱為A3:2017-暴露敏感數據，這并非根本原因。更新后的名稱側重于與密碼學相關的失敗，因為它之前已經隱含了。此類別通常會導致敏感數據暴露或系統受損。

　　A03:2021-注入下滑至第三名。94% 的應用程序針對某種形式的注入進行了測試，最大發生率為19%，平均發生率為3.37%?？缯军c腳本編寫現在是此版本中此類別的一部分。

　　A04:2021-不安全設計是2021年的一個新類別，重點關注與設計缺陷相關的風險。如果我們真的想作為一個行業“左移”，我們需要更多的威脅建模、安全設計模式和原則以及參考架構。不安全的設計不能通過完美的實現來修復，因為根據定義，從來沒有創建所需的安全控制來防御特定的攻擊。

　　A05:2021-安全配置錯誤從上一版的第6名上升；90% 的應用程序都針對某種形式的錯誤配置進行了測試，平均發生率為 4.5%，超過208,000次 CWE 映射到此風險類別。隨著更多轉向高度可配置的軟件，看到這一類別上升也就不足為奇了。

　　A06:2021-易受攻擊和過時的組件之前的標題是使用具有已知漏洞的組件。該類別從2017年的第9位上升，是我們難以測試和評估風險的已知問題。它是唯一沒有任何通用漏洞披露（CVE）映射到包含的CWE的類別。

　　A07:2021-識別和身份驗證失敗之前是斷開的身份驗證，并且從第二名下滑，現在包括與識別失敗更多相關的CWE。這個類別仍然是前10名的一個組成部分，但標準化框架的可用性增加似乎有所幫助。

　　A08:2021-軟件和數據完整性故障是2021年的一個新類別，專注于在不驗證完整性的情況下做出與軟件更新、關鍵數據和 CI/CD 管道相關的假設。來自通用漏洞披露/通用漏洞評分系統 （CVE/CVSS） 數據的最高加權影響之一映射到該類別中的10個CWE。A8:2017-不安全的反序列化現在是這個更大類別的一部分。

　　A09:2021-安全日志記錄和監視失敗之前是A10:2017-日志記錄和監視不足。此類別已擴展為包括更多類型的故障，難以測試，并且在CVE/CVSS 數據中沒有得到很好的表示。但是，此類故障會直接影響可見性、事件警報和取證。

　　A10:2021-服務器端請求偽造數據顯示，發生率相對較低，測試覆蓋率高于平均水平，并且利用和影響潛力的評級高于平均水平。此類別代表安全社區成員告訴我們這是很重要的場景，即使目前數據中沒有說明這一點。