想象一下，你正在一條長路上開車，來到一條隧道，這條隧道可以讓你節省幾個小時的路程時間。你把車停在護欄前，說：“嘿，我可以從這里過去嗎？”
“當然可以！”服務員回答道，“我們會把您的車裝到那輛卡車的后面，然后我會開過去，在另一邊和您會合。”您會在不檢查服務員的駕駛證、卡車狀況或他們是否有保險的情況下把鑰匙交給服務員嗎？
這個比喻并不微妙，但本質上這就是許多開發人員在注冊并開始使用第三方 API時沒有先進行審查時所做的事情。
根據 Gartner 的 2024 年 API 戰略調查，82% 的受訪者在其組織內使用 API，而高達 71% 的受訪者正在使用第三方（SaaS 供應商）提供的 API。如果沒有采取正確的措施來確保安全實施，這可能會成為一個問題。
下面，我們將探討第三方 API 增長背后的一些動機因素、不謹慎使用它們可能導致的問題，以及減輕這些風險的一些方法。
現在，幾乎四分之三的組織都或多或少地依賴第三方 API。隨著各家公司紛紛將生成式 AI 集成到產品中（OpenAI 的 API 等產品推動了這一進程），我們預計上述 71% 的數字將進一步上升。
問題在于，隨著某些 API 成為事實上的現狀，我們可能傾向于毫無疑問地信任它們返回的數據。這個問題不僅限于與 genAI 相關的 API（它本身就以制作可疑內容而聞名），還延伸到那些以前被認為是“黃金標準”的 API。
舉個例子，最近有一波抱怨說谷歌地圖越來越糟糕。他們的 API 已被 Domino’s、Uber 和數百萬其他組織使用。盡管有些人對路線選擇和數據新鮮度表示擔憂，但公司仍在蜂擁而至。無論其提供商的知名度有多高，我們都不應假設 API 是萬無一失的。
在最近一篇關于使用生成式 AI 增強產品功能的文章中，我們提到了加拿大航空被迫接受聊天機器人承諾的折扣。加拿大法院裁定，聊天機器人不能作為單獨的法律實體承擔責任，如果您打算在自己的產品中貼牌 API 驅動的 genAI 產品，這一點至關重要。
事實上，OWASP 將對 LLM 的過度依賴列入了LLM 申請的十大因素中。根據 OWASP 的說法，“過度依賴 LLM 且缺乏監督的系統或人員可能會因 LLM 生成的不正確或不適當內容而面臨錯誤信息、溝通不暢、法律問題和安全漏洞。”
雖然這并不意味著您應該完全忽視genAI API可以增加的價值，但它應該是整個實施和評估過程中的一個重要考慮因素。
談到 API 的不安全使用，OWASP認為，一些開發人員可能過于信任從第三方 API 收到的數據。他們甚至可能因此采用較弱的安全標準，尤其是在使用成熟的 API 的情況下。
語法和語義輸入驗證可以減少 SQL 注入和其他攻擊的影響。這樣做可能涉及驗證結構化字段的語法或值的上下文正確性。無論如何，在處理來自第三方 API 的數據時都應考慮輸入驗證。
我們最近寫了一篇關于嘗試破解您自己的 API 的文章。考慮您的產品與之交互的外部 API 和數據源絕對應該成為此API 安全測試過程的一部分。還值得看看 API 提供商為保護其服務而采取的其他措施。
許多 API 提供商都提供狀態頁面，詳細說明正常運行時間、過去發生的事件和其他相關信息。例如，在撰寫本文時， OpenAI 的 API 正常運行時間為 99.86%。查看解決問題所需的時間以及服務的整體正常運行時間，將讓您了解公司對中斷相關問題的響應程度。
DDoS 攻擊對第三方 API 構成了重大威脅，而速率限制是防止這種攻擊的好方法。在我們最近的速率限制成功指南中，我們討論了這種方法對于減輕數據泄露影響的價值。您正在考慮的服務是否使用了它？
在理想情況下，API 提供商會對他們的正常運行時間和速率限制統計數據感到滿意，并愿意與最終用戶共享這些數據。如果他們猶豫不決，那么你應該問問自己為什么。
一般來說，發布 API 的新版本是一件好事。API版本控制意味著希望修復當前存在的問題或向響應添加新的端點/參數。然而，缺點是過度的版本控制可能會導致重大更改。這可能會讓您作為 API 使用者難以實施修補程序，直到文檔更新以反映您需要在應用程序中進行的必要更改。
有時，開發人員會繼續托管與其 API 的棄用版本有關的文檔，以及有關他們對服務所做的重大更改的補充信息。從整體上看，可以幫助分析公司更改其 API 的頻率、他們過去是否遇到過重大問題等等。
正如 OWASP 的 API 安全十大概述中所述，不當的庫存管理會對 API 造成重大風險，例如，當舊 API 版本或僵尸端點未修補地運行或使用較低的安全要求時。
對于影子 API而言，組織可能根本沒有管理或保護 API。在決定使用 API 之前，嘗試發現文檔（和數據流）盲點始終是明智之舉。OWASP 建議查找以下內容：
查看 API 的文檔是否最新、全面且完全透明。
不幸的是，在別人的土地上建造建筑物總是存在一定的風險。正如我們上面所看到的，依賴沒有得到妥善保護或在某種程度上不可靠的第三方 API 可能會導致災難。或者，更有可能的是，它可能只會導致輕微的挫敗感。
隨著API 優先設計運動的興起，更不用說使用 AI 和 LLM API 集成 genAI 功能的壓力越來越大，我們預計 2024 年及以后 API 的消費范圍將比現在更加廣泛。
第三方 API 的性能（正常運行時間、版本控制、安全措施）一直都很重要。不過，許多組織現在對它們的依賴程度凸顯了在使用它們之前確保其質量的重要性。如果您沒有盡到應有的謹慎，那么審核現有集成還為時不晚。
作為 API 開發人員，您已經知道 API 的質量標志是什么樣的。如果第三方 API 顯示出讓您不滿意的缺陷，那么最好避免使用它。或者，回到之前的比喻，尋找另一條隧道……
文章來源：6 Potential Risks of Using Third-Party APIs
<center id="qteh0"></center>