應用程序端點和API端點看起來差不多。因為從技術(shù)角度看，如果它們是RESTful（大多數(shù)都是RESTful），它們的調(diào)用方式是一樣的，都是通過HTTPS，通常使用GET方法。通常不同的是隨請求發(fā)送的有效載荷。對于API來說，這通常包含一些JSON或XML格式的數(shù)據(jù)，而Web應用請求可能什么都不包含。
盡管如此，F(xiàn)5年度研究的主要發(fā)現(xiàn)之一仍然表明，企業(yè)在安全方面將API與應用程序區(qū)別對待。我們根據(jù)以下數(shù)據(jù)推斷出這一點：41%的企業(yè)至少擁有與應用程序相同或更多數(shù)量的API，但對確保提供相同等級的API安全服務的重視程度卻較低。
您可能會問，企業(yè)中的API數(shù)量怎么會超過應用程序呢？雖然用于內(nèi)部服務間通信（如微服務）的API與其支持的服務肯定是緊密耦合的，但當API用于呈現(xiàn)外部接口時，情況就不一定如此了。
API從何而來
參考2021年的調(diào)查，61%的受訪者告訴我們，作為現(xiàn)代化的一種方法，他們正在"添加一層API，以實現(xiàn)現(xiàn)代用戶界面"。而在2022年，這一比例為45%。這意味著，實現(xiàn)現(xiàn)代用戶界面的API并不一定是直接連接到應用程序的工具。它們可能是促進現(xiàn)代用戶界面和應用程序（如移動應用程序和數(shù)字服務）的外層，也可能是旨在實現(xiàn)合作伙伴和供應鏈通信的外層。這些用例由負載均衡中的API網(wǎng)關和7層路由提供支持，它們通常提供一定程度的轉(zhuǎn)換功能，允許它們從API端點轉(zhuǎn)換到應用程序端點，從而實現(xiàn)API門面，就像那些使舊式美國西部老建筑看起來比實際更壯觀的外墻一樣。
當然，還有相當數(shù)量的API是面向公眾的實體，附屬于應用程序并通過網(wǎng)絡（通常是HTTPS）訪問。
無論它們是如何出現(xiàn)的，面向公眾的API都會受到許多與應用程序相同的攻擊。當涉及Bot時尤其如此，因為具有良好文檔的API可以讓攻擊者輕松編寫大規(guī)模攻擊腳本。
例如，2023年受F5分布式云Bot防護的交易中，僅有13%多一點是自動完成的。也就是說，使用的是腳本或軟件，而不是使用網(wǎng)頁或移動應用程序的人類。這些交易通過API和應用程序進行。這些自動交易中肯定有一部分是"惡意Bot"，我們的安全服務阻止了它們的惡意企圖。（您可以在F5Labs報告中更深入地了解它們的企圖）。
因此，當我們根據(jù)受訪者自我報告的API數(shù)量來了解他們?nèi)绾慰创鼴ot管理時，我們驚訝地發(fā)現(xiàn)，Bot管理的重要性非常低。
從這些柱形圖中可以看出，雖然對API網(wǎng)關的重視程度似乎與所管理的API數(shù)量相稱，但對Bot管理的重視程度卻不盡相同。事實上，情況完全相反！隨著API數(shù)量的增加，Bot管理的重要性似乎在迅速下降。
當然，這些API大部分都是內(nèi)部應用程序接口。也就是說，它們是微服務之間的東西向API，不會暴露給可能是惡意Bot的外部行為者。
但這種情況并不是絕對的。鑒于去年我讀到的關于攻擊者通過API獲取訪問權(quán)限的文章數(shù)量，我猜測外部攻擊者比我們想象的要多得多。
因此，現(xiàn)在是時候提醒人們，雖然有許多惱人的Bot—如搶貨機器人—通過搶購高需求商品來擾亂業(yè)務，但也有大量Bot的唯一目的是嗅出漏洞并對其進行攻擊。無論漏洞在API還是應用程序中。
因此，企業(yè)最好采用全方位的安全策略來保護API，并最終保護其業(yè)務。Bot管理無疑是可信賴的安全解決方案之一，應被視為任何安全策略的關鍵組成部分。
說到底，Bot并不在意要攻擊的端點是屬于應用程序還是API。它們會同時發(fā)起攻擊。
這意味著企業(yè)需要通過檢測Bot來保護應用程序和API，并阻止災害發(fā)生。
閩公網(wǎng)安備 35010202001226號
