您可能知道 Cloudflare 是一家為近 20% 的 Web 提供支援的公司。但為網站和靜態內容提供支援和保護只是我們所做工作的一小部分。事實上，我們網路上超過一半的動態流量不是由網頁組成，而是由應用程式開發介面 (API) 流量組成，API 流量是使技術發揮作用的管道。本部落格介紹《2024 年 API 安全性報告》並對其進行補充，其中詳細介紹了我們如何保護客戶，以及這對 API 安全的未來意味著什麼。與其他產業 API 報告不同，我們的報告不是基於使用者調查，而是基於真實的流量資料。
在今年的報告中，需要瞭解的最關鍵一點是：許多組織缺乏準確的 API 詳細目錄，即使他們認為自己能夠正確識別 API 流量。Cloudflare 協助組織使用兩種方法來探索所有面向公眾的 API。首先，客戶設定我們的 API 探索工具來進行監控，以識別其已知 API 流量中存在的權杖。然後，我們使用機器學習模型，不僅掃描這些已知的 API 呼叫，還掃描_所有_ HTTP 要求，識別可能下落不明的 API 流量。這些方法之間的差異是驚人的：我們透過基於機器學習的探索發現的API 端點比自我報告的方法多了 30.7%，這表明近三分之一的 API 是「影子API」——並且可能沒有得到適當的清查和保護。
請繼續閱讀我們的首份 API 安全性報告，以瞭解更多內容和亮點。在完整報告中，您將找到有關我們發現和預防的威脅的最新統計資料，以及我們對 2024 年的預測。我們預測，組織缺乏對 API 安全性的關注將導致複雜性增加、失去控制，以及對產生式 AI 的存取增加將導致更多的 API 風險。我們還預計，2024 年 API 業務邏輯攻擊將會增加。最後，上述所有風險都會導致圍繞 API 安全性的監管加碼。
隱藏的攻擊面
網頁和 API 有何不同？API 是應用程式在背景中擷取資料或要求其他應用程式完成工作的快速簡便的方法。例如，任何人都可以編寫天氣應用程式，而無需成為氣象學家：開發人員可以編寫頁面或行動應用程式的結構，並利用使用者的位置向天氣 API 請求天氣預報。重要的是，大多數終端使用者並不知道資料是由天氣 API 提供的，而不是應用程式的擁有者提供的。
雖然 API 是網際網路的關鍵管道，但它們也容易被濫用。Optus 的 API 驗證和授權中的缺陷已導致一個威脅行為者出售 1000 萬筆使用者記錄，政府機構已對這些確切的 API 攻擊發出警告。組織中的開發人員通常會建立面向網際網路的 API，供自己的應用程式使用以提高運作效率，但保護這些新公用介面的責任在於安全團隊。如果記錄 API 並將其提請安全團隊注意的流程不明確，它們就會成為影子 API——在生產中運作，但組織毫不知情。這就是安全挑戰開始出現的地方。
為了幫助客戶解決這個問題，我們推出了 API Discovery。當我們介紹最新版本時，我們提到很少有組織擁有準確的 API 詳細目錄。安全團隊有時被迫採用「傳送電子郵件並詢問」的方法來建立詳細目錄，這樣做的結果是，一旦應用程式發布 API 有變化的新版本，回應就會過時。更好的方法是透過程式碼庫變更來追蹤 API 變更，以跟上新版本的發佈。然而，這仍然有一個缺點，只能清點主動維護的程式碼。儘管舊版應用程式仍在接收生產流量，但它們不會有新版本發布。
Cloudflare 的 API 管理方法包括結合使用基於機器學習的 API 探索和網路流量檢查來建立全面、準確的 API 詳細目錄。這是我們的 API Gateway 產品不可或缺的一部分，客戶可以在其中管理其面向網際網路的端點並監控 API 健康情況。API Gateway 還允許客戶使用工作階段識別碼（通常是標頭或 cookie）來識別其 API 流量，這有助於專門識別探索過程的 API 流量。
如前所述，我們的分析表明，即使是知識淵博的客戶也常常會忽略其 API 流量的很大一部分。將基於工作階段的 API 探索（使用 API 工作階段來找出流量）與基於機器學習的 API 探索（分析_所有_傳入流量）進行比較，我們發現，後者發現的端點平均多出 30.7%！如果沒有廣泛的流量分析，您可能會漏掉幾乎三分之一的 API 詳細目錄。
即使您不是 Cloudflare 客戶，您仍然可以開始建立 API 詳細目錄。API 通常以稱為OpenAPI 的標準化格式進行編目，並且許多開發工具可以建立 OpenAPI 格式的結構描述檔案。如果您有該格式的檔案，您可以透過收集這些結構描述來開始自行建立 API 詳細目錄。以下是如何從結構描述檔案拉取端點的範例，假設您有一個名為 `my_schema.json` 的 OpenAPI v3 格式檔案：
除非您從應用程式開發流程開始就一直在產生 OpenAPI 結構描述並追蹤 API 詳細目錄，否則您的生產應用程式 API 詳細目錄中就很可能會遺漏一些端點。
import json
import csv
from io import StringIO
# Load the OpenAPI schema from a file
with open("my_schema.json", "r") as file:
schema = json.load(file)
# Prepare CSV output
output = StringIO()
writer = csv.writer(output)
# Write CSV header
writer.writerow(["Server", "Path", "Method"])
# Extract and write data to CSV
servers = schema.get("servers", [])
for server in servers:
url = server['url']
for path, methods in schema['paths'].items():
for method in methods.keys():
writer.writerow([url, path, method])
# Get and print CSV string
csv_output = output.getvalue().strip()
print(csv_output)精確的速率限制可以最大程度減少攻擊的可能性
當談到製止濫用行為時，大多數從業者首先想到的是限速。**對 API 實作限制是控制濫用並防止來源意外過載的重要工具。**但怎麼知道您選擇的限速方法是否正確呢？方法可能有所不同，但它們通常歸結為所選的錯誤代碼以及限制值本身的依據。
對於某些 API，從業者設定限速錯誤以傳回 HTTP 403（禁止）回應，而其他 API 則傳回 HTTP 429（太多要求）回應。使用 HTTP 403 似乎沒有問題，直到您意識到其他安全性工具也以 403 代碼作為回應。當您遭受攻擊時，可能難以弄清楚哪些工具對哪些錯誤/封鎖負責。
如果使用 HTTP 429 來回應速率限制，攻擊者會立刻知道他們已經受到速率限制，並能剛好保持在限製水平下以免被偵測到。如果您只是為了確保後端系統穩定而限制要求，這樣做或許沒問題，但它可能會向攻擊者暴露您的底牌。此外，攻擊者可以「擴展」到更多 API 用戶端，從而成功發出超過速率限制的要求。
這兩種方法各有利弊，但我們發現到目前為止，在所有 4xx 和 5xx 錯誤訊息中，大多數 API 都以 HTTP 429 作為回應（接近 52%）。
除了使用回應代碼外，限速規則本身的情況如何？實作基於 IP 位址的要求限制可能很有誘惑力，但我們建議您將基於工作階段 ID 的限製作為最佳做法，並僅在沒有工作階段 ID 時才退而採用 IP 位址（或 IP+JA3 指紋）。基於使用者工作階段而非 IP 設定限速，將能可靠地識別您的真實使用者，並最大程度減少因共用 IP 空間而導致的誤判。Cloudflare 進階限速和 API Gateway 的容量濫用防護便於透過分析每個 API 端點的工作階段流量來實施限制，並為設定每個端點的限速提供一鍵式解決方案。
為確定您的限速值，Cloudflare API Gateway 會對您的工作階段要求統計資料進行計算。依照客戶設定的 API 工作階段識別碼，我們識別前往 API 的_所有_工作階段，觀察每個工作階段的要求分佈情況，並建議一個限制值。然後我們針對這個分佈的 p50、p90 和 p99 計算統計 p 值（描述不同流量組的要求率），並使用該分佈的變化幅度來產生 API 詳細目錄中每個端點的建議閾值。建議值可能與 p 值不一致，這是一個重要的區別，也是不單獨使用 p 值的原因。除了建議值，API Gateway 也會告知使用者我們對推薦值的信心。通常情況下，我們能收集到的 API 工作階段越多，我們對建議值的信心就越足。
啟用限速非常簡單，僅需按一下「建立規則」連結，API Gateway 會自動將您的工作階段識別碼帶到「進階限速」規則建立頁面，確保您的規則具有高度準確性，以防禦攻擊並最大程度減少誤判（與過於寬泛的傳統限制相比）。
API 也是 Web 應用程式攻擊的受害者
API 也無法免於常見的 OWASP Top 10 攻擊，例如 SQL 資料隱碼攻擊。API 要求的正文內容也可能像網頁表單輸入或 URL 參數一樣成為資料庫輸入。重要的是，確保您的 Web 應用程式防火牆 (WAF) 也保護您的 API 流量，以防這些類型的攻擊。
事實上，當我們查看 Cloudflare 的 WAF 受管理規則時，資料隱碼攻擊是 Cloudflare 觀察到的針對 API 的第二常見威脅手段。最常見的威脅是 HTTP 異常。HTTP 異常的範例包括格式錯誤的方法名稱、標頭中的空位元組字元、非標準連接埠或 POST 要求的內容長度為零。以下是我們觀察到的針對 API 的其他主要威脅的統計資料：
圖表中沒有驗證和授權失效。驗證和授權失效是指 API 無法檢查向 API 傳送資訊要求的實體是否確實有權要求該資料。另一種情況是，攻擊者試圖偽造憑證並將限制較少的權限插入到具有更受限權限的現有（有效）憑證中。OWASP 將這些攻擊分為幾種不同的類型，但主要類別是物件層級授權失效 (BOLA) 和功能層級授權失效 (BFLA) 攻擊。
BOLA/BFLA 攻擊得以成功的根本原因在於，來源 API 沒有根據要求這些記錄的身分檢查資料庫記錄的正確擁有權。追蹤這些特定的攻擊可能很困難，因為權限結構可能根本不存在、不充分或實施不當。這就出現了一個先有雞還是先有蛋的問題。如果我們知道正確的權限結構，阻止這些攻擊將會很容易，但如果我們或我們的客戶知道正確的權限結構或能保證其執行，那麼這些攻擊從一開始就不會成功。請繼續關註我們未來的 API Gateway 功能發布，屆時我們將利用對 API 流量常態的瞭解，自動建議安全性原則，突出顯示並阻止 BOLA/BFLA 攻擊。
即使您沒有可用的精細授權原則，也可以透過以下四種方法來堵住 API 可能存在的驗證漏洞：
首先，除非存在企業核准的例外，否則對每個可公開存取的 API 強制執行驗證。關注 mTLS 和 JSON Web 權杖等技術。
限制針對伺服器的 API 要求的速度，以減緩潛在攻擊者的速度。
封鎖異常的敏感性資料流出量。
阻止攻擊者跳過合法的 API 要求序列。
令人驚訝的是，API 是由人類驅動的，而不是機器驅動的
如果您從智慧型手機出現之前、上網的人還很少的時候就開始關注技術，您可能會不禁認為 API 僅被用於機器與機器之間的通訊，例如夜間的批次作業處理。然而，事實完全不是那樣。正如我們所討論的，許多 Web 和行動應用程式都是由 API 驅動的，它們支援從驗證到交易再到媒體檔案服務的各種事務。隨著人們使用這些應用程式，API 流量也相應增加。
我們可以透過觀察假日期間的 API 流量模式來說明這一點。在假日期間，人們聚集在朋友和家人身邊，花更多的時間進行面對面的社交活動，減少上網時間。我們在下面的全球 API 流量圖表上標註了常見的假日和促銷活動。請注意，在黑色星期五和網路星期一期間，當人們在線上購物時，流量會達到+10% 左右的高峰，但在聖誕節和元旦期間，流量出現下降。
這種模式與我們在常規 HTTP 流量中觀察到的情況非常相似。很明顯，API 不再只是自動化程序的領域，還與人類行為和社會趨勢有著錯綜複雜的連結。
建議
全面的 API 安全性並沒有萬能的解決方案。為了取得最佳效果，Cloudflare 推薦四種策略來改善 API 的安全狀態：
將 API 應用程式開發、可見性、效能和安全性與可保持最新 API 詳細目錄的統一控制平面相結合。
透過利用機器學習技術的安全工具，釋放人力資源並降低成本。
為您的 API 採用主動安全性模式（有關主動和被動安全性模式的說明，請參閱下文）。
隨著時間的推移，衡量並改進您組織的 API 成熟度（另請參閱下文對 API 成熟度的說明）。
「主動」或「被動」的安全性模式是什麼意思？ 在被動模式中，安全工具會尋找已知的攻擊跡象，並採取動作來阻止這些攻擊。在主動模式中，安全工具會尋找已知的良好要求，並僅允許這些要求通過，阻止所有其他要求。針對 API 的結構，採用主動安全性模式才能獲得更高層級的安全性。您也可以結合不同的安全性模式，例如在被動模式中使用 WAF，以及在主動模式中使用 API 結構描述驗證。
以下是隨著時間的推移衡量組織 API 安全成熟度的快速方法：新手組織從編制第一個 API 詳細目錄開始，無論多麼不完整。更成熟的組織將努力實現 API 詳細目錄準確性和自動更新。最成熟的組織會對他們的 API 以主動安全性模式積極執行安全性檢查，實施 API 結構描述、有效驗證，並檢查濫用行為的跡象。
預測
最後，我們對 2024 年及以後有四大預測：
**喪失控制和複雜性增加：**我們對 API 安全性和管理領域的從業者進行了調查，73% 的人回答說安全要求會幹擾他們的生產力和創新。再加上日益龐雜的應用程式和不準確的詳細目錄，API 風險和複雜性將會上升。
**更容易存取 AI 會導致更多 API 風險：**產生式 AI 的興起帶來了潛在風險，包括 AI 模型的 API 容易受到攻擊，而且開發人員還會發佈 AI 編寫的有缺陷的程式碼。Forrester 預測，到 2024 年，如果不採取適當的防護機制，「至少有三次資料外洩會被公開歸咎於 AI 產生的不安全程式碼——由於產生的程式碼本身的安全瑕疵，或者 AI 建議的依存性中的漏洞」。
**基於業務邏輯的詐欺攻擊增加：**專業詐欺者像經營企業一樣經營他們的業務，並且他們也和其他人一樣擁有成本。我們預計攻擊者將比前幾年更有效地針對 API 執行詐欺傀儡程式。
**監管加碼：**直接針對 API 安全性的 PCI DSS 第一版將於 2024 年 3 月生效。請與您的稽核部門查看您所在行業的特定要求，以便在新要求生效時做好準備。
如果您對完整報告感興趣，可以在此處下載《2024 年 API 安全性報告》，其中包含有關我們建議的完整詳細資訊。
Cloudflare API Gateway 是我們的 API 安全性解決方案，可供所有企業方案客戶使用。如果您未訂閱 API Gateway，請按一下此處檢視您的初始 API Discovery 結果並在 Cloudflare 儀表板中開始試用。若要瞭解如何使用 API Gateway 來保護您的流量，請按一下此處檢視我們的開發文件，並按一下此處獲取我們的入門指南。