11月3日，threatpost網站釋出了傑森肯特（Jason Kent）的文章。現在此對該文章作摘譯如下，以供讀者參考。
API（應用程式程式設計介面）安全風險在過去兩年中發生了巨大變化。下面將討論一下當今最重要的 API 安全問題以及如何解決這些問題。
“作為一名長期的OWASP成員和應用程式安全從業人員，我想與大家分享一下我的想法，新發布的OWASP Web App Top 10（應用安全風險Top 10）將會如何影響API security Top 10（API安全風險Top 10）的更新。”傑森肯特說。上一輪API security Top 10釋出於2019年12月。
（圖片來源：threatpost）
最近更新了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中可以得出許多相似之處：
（圖片來源：threatpost）
在下一輪API安全風險Top 10列表中，我希望術語保持一致，儘管我不期望類似的定位，因為API和web應用之間存在明顯的差異。我預計新的Web應用程式列表會有一些重疊，但會有一些特定於API的威脅，比如：
（圖片來源：threatpost）
讓我們來看看對未來列表的預測。
下一版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%。跨站點指令碼編寫現在是此版本中此類別的一部分。
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-伺服器端請求偽造
資料顯示，發生率相對較低，測試覆蓋率高於平均水平，並且利用和影響潛力的評級高於平均水平。此類別代表安全社群成員告訴我們這是很重要的場景，即使目前資料中沒有說明這一點。
（來源：threatpost等。本文參考內容均來源於網路，僅供讀者瞭解和掌握相關情況參考，不用於任何商業用途。侵刪）
