當今社會已進入一個信息廣泛互聯和共享的時代，API技術逐漸成爲了現代數字業務環境的基礎組成，也是企業數字化轉型發展戰略實現的核心要素。幾乎所有的企業都依賴API進行服務連接、傳輸數據和控制系統。然而，API的爆炸性應用也極大地擴展了企業的攻擊面，增加了企業對API安全性的需求。
API安全的現狀
Salt Security是一家API安全公司，它提供了一個整體保護平臺來防止API攻擊，並使用機器學習和AI來自動連續地識別和保護API。根據Salt Security2022年最新發布的《API安全趨勢調查報告》數據顯示：
-
2022年，平均每個受訪企業的API數量較去年增長82%。同時，惡意API流量佔比約爲2.1%，比去年激增117%；
-
API攻擊正在引發嚴重的安全問題，有94%的受訪者表示他們在過去一年內遇到過API安全問題；
-
近一半（47%）的受訪者表示，他們在企業應用的API中檢測出安全漏洞；38%的受訪企業遭遇過API引發的身份安全問題，31%的受訪企業遭遇過API引發的敏感數據泄露和隱私安全事件；
-
40%的受訪者表示將努力解決API應用安全問題，但只有11%的受訪者表示，目前已經使用了針對性技術來進行API安全測試和保護工作。
以上研究結果表明，有很多企業還沒有對API面臨的安全威脅保持足夠的重視。但實際上，它們可能難以承受自己的商譽和誠信受到API安全事件帶來的損害。因此，所有企業都需要努力解決API的安全問題，確保對網絡中最常見和最嚴重的API安全威脅進行補救。
API安全風險與防護建議
API安全不僅僅是修復單個漏洞的問題。相反，它需要IT團隊的全面關注。他們必須從更廣泛的角度解決API網絡安全缺口。任何API中的某一個安全問題都可能導致不必要的後果。 以下整理了一些最危險的API安全風險和防護建議。
風險一
影子API、殭屍API
影子API是目前API安全中最爲突出的問題，由於API的使用率激增，企業往往無法全部跟蹤管理，因此，一些API無法及時進行維護更新，從而成爲了被惡意黑客公開利用的漏洞。
與影子API類似，殭屍API對組織來說也是一個巨大的安全風險，其通常指的是舊的、很少使用的API版本。由於殭屍API很少得到安全團隊的注意，所以也給了犯罪分子惡意利用的可乘之機。
防護建議
及時維護更新API庫存表可以儘可能減少影子API或殭屍API的存在。爲此，組織必須要求IT團隊跟蹤和監視所有正在運行的API，以查找未解決的漏洞、故障或錯誤配置。組織還可以利用自動化API安全工具（如AppTrana）進行API庫存跟蹤。此外，所有開發人員和相關人員都應該確保所有API都有規範的文檔進行說明和映射。
風險二
不安全的資源展示
一些API需要向客戶端顯示可用資源列表以供使用者及時瞭解。該列表可能包括“用戶”或“小部件”等元素，當通過瀏覽器查看時，這些元素會以有組織的“分頁”（paginated）方式呈現。雖然這聽起來很有幫助，但任何展示資產信息（explicit information，如用戶的PII數據和資源列表）的API都容易遭受來自攻擊者的數據抓取，並從中提取敏感信息，例如受影響的web應用程序使用情況、客戶電子郵件列表等等。
防護建議
可以限制展示分頁和資源列表的顯示，以避免數據被惡意抓取。例如爲查看特定資源的API調用指定一個時間段。或者，爲用戶設置API訪問密鑰，並限制API密鑰可能被使用的次數，超過次數將撤銷訪問並阻止API連接。
風險三
未經身份驗證的API
很多企業中存在大量歷史遺留應用程序，因此，使用API而不進行身份驗證是目前很常見的現象。這些未經身份驗證的API一旦公開暴露，就會對企業的應用系統安全構成威脅。雖然如何管理遺留API本身就是一種風險，但讓未經身份驗證的API獲取敏感數據（如PII）對於企業將是一個更大的安全隱患，甚至會產生法規遵從和合規性方面的問題。
防護建議
強制進行API身份驗證，以防止未經請求的API訪問敏感數據資源。雖然它可能不是一個完善的解決方案，但實現身份驗證可以控制API的訪問範圍，也能幫助IT管理人員在惡意訪問嘗試的情況下識別出訪問入口點。IT團隊還應該定期進行API檢查，以確保足夠的API安全性，特別是在升級遺留應用程序或報廢與這些API相關的老舊設備時。
風險四
未經授權的API
對所有API進行強制身份驗證本身並非一個完善的、有包容性的解決方案。安全團隊還應該實現對API的授權訪問管理，以將安全風險降至最低。使用經過身份驗證但未經授權的API是IT團隊經常難以解決的固有API安全風險。攻擊者可以通過各種方法（例如枚舉用戶標識符）獲得經過身份驗證的訪問，而不考慮擬攻擊用戶的權限級別，從而大量利用此類未經合理授權的API。
防護建議
應用程序開發人員經常忽略對API進行合理授權，而經過身份驗證的用戶就可以對API執行任何預期的操作。因此，防止這種未經授權的API訪問需要開發人員實現安全檢查，例如用戶ID或創建訪問控制列表，以限制通過身份驗證的用戶訪問不屬於他們的API數據。
風險五
公開暴露的API密鑰
當不同的應用系統進行交互時，就需要通過API進行連接，這時候就需要一個密鑰進行安全性確認。開發人員應該在整合這些應用時，保證密鑰的安全性。但是很多開發人員爲了工作方便，會在開發過程中將API認證密鑰直接嵌入到API中，但是之後也未及時刪除。一旦這個API密鑰被攻擊者查詢獲得，就能夠以關聯合法用戶的身份，進行各種非法操作。
防護建議
一般的做法應該是隻將密鑰暴露給指定的用戶。而從長遠來看，在開發階段就有效規範安全管理流程可以防止密鑰泄露和惡意抓取等API應用威脅。
風險六
API監控不足
API監控不足也可歸因於企業對API應用安全性的忽視。當API應用缺少監控時，會給潛在的攻擊者足夠的時間來建立對受損API的訪問並保持長期連接。這種隱形攻擊可能導致企業財產、商譽和數據資產的損失。根據OWASP的說法，組織檢測修復漏洞的平均時間約爲200多天，因此IT人員需要在更短時間裏發現API應用的異常情況。
防護建議
企業要對API的應用安全問題提高警惕。常規的API日誌記錄不應該侷限於API請求。相反地，它必須涵蓋用戶行爲分析並存儲大約一年的日誌。組織必須定期開展API安全應用審計，以確保足夠的API日誌記錄和安全的日誌存儲。
風險七
應用服務器安全性差
不安全的應用服務器可能泄漏大量數據，不安全或配置錯誤的API應用也反映出組織存在巨大的網絡安全缺口。當開發人員未能部署基本的安全措施（如實現HTTPS通信）時，通常會出現此問題。不幸的是，許多web應用程序仍然支持HTTP通信，這樣就會輕易暴露API密鑰等敏感數據。由於web瀏覽器並不直接處理API，像HTTPS-redirect（重定向）這樣的特性在這裏不能受到任何保護。
防護建議
採用HTTPS-only-like方法是防止應用服務意外數據暴露的關鍵。開發人員還可以通過部署負載均衡設備，實現利用SSL來加密數據和阻止不安全的HTTP請求。