API安全性已經成為企業組織的一個關鍵性業務發展問題，而非僅僅是信息安全的問題，很多企業由于擔心API安全問題，而不得不推遲新業務系統的應用。由于當前的技術工具和安全流程無法跟上API安全發展的步伐。組織必須尋找更有效的API安全防護措施，在API應用生命周期的每個階段進行安全性驗證和保護。
2023年API安全事件
API安全公司FireTail認為，2023年將成為API泄露事件創紀錄的一年。根據該公司的監測，今年以來已有超過5億條數據信息因為易受攻擊的API應用而導致了泄露，其中較為嚴重的API安全事件包括：
- 2023年1月，豐田（Toyota）、梅賽德斯（Mercedes）、寶馬（BMW）和其他十幾個汽車品牌曝出API相關漏洞。遠程信息處理系統中的API漏洞不僅僅暴露了客戶數據，還允許惡意行為者遠程實現按喇叭、閃爍燈、遠程跟蹤、開關車門、啟停車輛等操作；
- 同月，T-Mobile公開承認，黑客利用一個API漏洞竊取了3700萬客戶的數據；
- 2023年2月，Trustwave研究人員發現，Finsify公司的Money Lover個人理財應用暴露了其500多萬用戶的電子郵件地址和數字錢包賬號；
- 2023年3月，CISA發布了一份關于Nexx車庫門控制器和智能報警器的安全公告，在超過40,000臺設備中發現了存在多個API應用漏洞，攻擊者可以利用這些漏洞竊取個人信息，如物理地址、打開車庫門和關閉警報；
- 2023年6月，Patchstack研究人員報告稱，WooCommerce公司最受歡迎的WordPress支付插件WooCommerce Stripe Gateway中存在一個嚴重API漏洞，允許未經身份驗證的用戶查看用戶訂單的敏感數據，包括電子郵件和完整地址。該漏洞累計影響了50萬以上用戶的個人隱私安全；
- 同樣在6月，Eaton Works的一名研究人員入侵了本田汽車電子商務平臺，通過利用API接口漏洞，他可以重置任何賬戶的密碼，并獲得完整的客戶信息、經銷商信息、付款密鑰和內部財務報告。該事件導致了近40,000條車主記錄暴露；
- 2023年7月，為超過18萬家企業提供云“目錄即服務”（directory-as-a-service）的軟件服務商JumpCloud公司，因API相關漏洞而全部更改了其API應用密鑰。
API應用安全挑戰
根據Enterprise Strategy Group公司對超過400家企業的調研統計，有超過92%的組織在過去12個月里至少經歷了一次與API相關的安全事件，而導致API應用安全事件日益普遍的原因主要包括：API生態系統的規模、應用復雜性和快速變化的本質。
研究人員發現，面對API應用快速增長，企業組織最擔憂的問題是缺少對API訪問行為的有效認證和控制。在不久前剛剛更新的2023年度“OWASP TOP 10 API安全風險”清單中，和身份驗證和授權相關的安全風險有四個。而FireTail API數據泄露跟蹤報告的相關數據也顯示，在今年所監測到的12起公共API應用數據泄露事件中，每一起都涉及至少一個身份驗證或授權方面的安全漏洞。
API安全應用的另一個重要挑戰是如何識別其中的關鍵數據以及如何監控這些數據在API生態系統中安全地流動。為了保證安全性，企業組織需要弄清楚他們最敏感的數據是什么、在哪里、誰可以訪問，并根據這些信息來設計API的安全性。不幸的是，很多公司需要手動操作來完成以上工作，這是一個緩慢且易出錯的過程，也無法真正理解API與其所連接的數據之間的邏輯關系。
缺乏可見性也是API安全應用的主要挑戰。畢竟，我們無法保護自己看不見的東西。在企業中，除了API應用的開發者，很少有人會意識到這些API的存在，這使得大量的API缺少維護，并經常容易被忽略。當組織缺乏適當的API可見性、治理機制和生命周期策略時，僵尸、影子和幽靈等可怕的API威脅就會出現。
最后，企業對API應用安全的保障能力存在不足。調查數據顯示，盡管有74%的受訪企業表示他們已經部署了API安全工具，但事實上并未形成有效的防護能力。很多傳統API管理工具，缺乏解決API特有漏洞所需的具體功能，也無法提供檢測特定API攻擊（比如撞庫攻擊和蠻力破解）所需的可見性。
API安全性自查清單
企業需要尋求更加有效API安全防護策略和方法，以減少API安全治理的復雜性和管理成本。
參考2023年度“OWASP TOP 10 API安全風險”清單，安全研究人員總結梳理了一份易于遵循的API安全性檢查清單，通過全面的API安全風險檢查，企業可以有效提升API應用的安全性。
OWASP - A1 ：對象級授權
- 驗證是否使用用戶策略和層次結構實現授權檢查；
- 驗證API是否需要依賴于從客戶端發送的身份ID，API應用應該檢查會話中存儲對象的ID；
- 驗證服務器配置是否按照所使用的應用服務器和框架的建議進行了加固；
- 驗證API是否實現了在每次客戶端請求訪問數據庫時檢查授權；
- 驗證API沒有使用隨機猜測ID（UUID）。
OWASP - A2：破損的認證
- 驗證是否全面認證所有API；
- 驗證密碼重置API和一次性鏈接是否允許用戶一起進行身份驗證，并受到嚴格保護；
- 驗證API是否實現標準的身份驗證，令牌生成，密碼存儲和多因素身份驗證；
- 驗證API是否使用了短期訪問令牌；
- 驗證API是否使用了嚴格的速率限制身份驗證，并實現鎖定策略和弱密碼檢查。
OWASP - A3：過度的數據暴露
- 驗證API是否依賴于客戶端來過濾數據；
- 驗證API響應性，并根據API使用者的實際需要調整響應；
- 驗證API規范性，定義所有請求和響應的模式；
- 驗證錯誤API響應是否已經明確定義；
- 驗證所有敏感或PII信息的使用是否有明確的理由；
- 驗證API強制響應檢查措施，以防止意外的數據和異常泄漏。
OWASP - A4：缺乏資源和速率限制
- 驗證是否根據API方法、客戶端和地址配置了速率限制；
- 驗證有效載荷限制是否已配置；
- 在執行速率限制時驗證壓縮比；
- 驗證計算/容器資源上下文中的速率限制。
OWASP - A5：無效的功能級授權
- 驗證默認情況下是否能夠拒絕所有訪問；
- 驗證API是否依賴于應用程序來強制管理訪問；
- 驗證所有不需要的功能是否都被禁用；
- 驗證計算/容器資源內容中的速率限制是否有效；
- 確保僅根據特定角色授予角色；
- 驗證授權策略是否在API中正確實現。
OWASP - A6：批量分配
- 驗證API是否自動綁定傳入數據和內部對象；
- 驗證API是否顯示定義組織期望的所有參數和有效負載；
- 驗證API在設計時是否精確定義了訪問請求中接受的模式、類型和模式，并在運行時強制執行它們。
OWASP - A7：安全配置錯誤
- 驗證API實現是否可重復，并且加固和修復活動已納入開發過程；
- 驗證API生態系統是否具有自動定位配置缺陷的過程；
- 驗證平臺是否在所有API中禁用了不必要的功能；
- 驗證API安全系統是否可以限制管理訪問；
- 驗證所有的輸出是否安全，包括錯誤的輸入；
- 驗證授權策略是否在API中正確實現。
OWASP - A8：請求偽造
- 驗證API對各類消費者的信任機制是否正確，即使是對內部員工的；
- 驗證API是否嚴格定義所有輸入數據：模式、類型、字符串模式，并在運行時強制執行；
- 驗證API是否可以對所有傳入數據進行驗證、過濾和阻斷；
- 驗證API是否定義、限制和執行API輸出，以防止數據泄漏。
OWASP - A9：資產管理不當
- 驗證平臺能否限制訪問任何不應公開的內容；
- 驗證API應用架構是否具備額外的外部安全控制，如API防火墻；
- 驗證一個API應用進程是否被有效地管理；
- 驗證架構是否實現嚴格的API身份驗證、重定向等。
OWASP - A10：日志記錄和監控不足
- 驗證API日志的完整性和準確性；
- 驗證日志格式是否可以被其他工具有效使用；
- 驗證API應用管理平臺是否對敏感日志進行了有效保護；
- 驗證API應用平臺是否包含足夠的詳細信息以識別攻擊者；
- 驗證平臺與SIEM等其他安全工具是否可以協同、集成。
參考鏈接：https://gbhackers.com/api-security-checklist/
