大部分現代網際網路依賴於 API 來運作。API 安全性是保護 API 免受攻擊和資料外洩的過程。
閱讀本文後，您將能夠：
相關內容
訂閱 TheNET，這是 Cloudflare 每月對網際網路上最流行見解的總結！
複製文章連結
應用程式程式設計介面 (API) 是一個軟體與另一個軟體互動的方式。如果一個程式或應用程式有 API，外部用戶端可以向它請求服務。
API 安全性是保護 API 免受攻擊的過程。正如應用程式、網路和伺服器可能會受到攻擊一樣，API 也可能成為許多不同威脅的受害者。
API 安全性是 Web 應用程式安全性的核心部分。大多數現代 Web 應用程式都依賴 API 來運作，而 API 允許外部各方存取它，從而給應用程式帶來了額外的風險。就好像一家向公眾開放辦公室的企業：場所內有更多人，其中一些人可能不為企業員工所知，這會帶來更大的風險。同樣，API 允許外部人員使用程式，從而給 API 服務的基礎架構帶來更多風險。
API 安全性策略可以幫助緩解這些和其他風險。
強大的驗證和授權措施有助於確保資料不洩露且只有授權的用戶端才會發出 API 要求。DDoS 防護和限速可以關閉 DDoS 攻擊。結構描述驗證和使用 Web 應用程式防火牆 (WAF) 可以封鎖漏洞利用。
限速對某人在特定時間範圍內重複一個動作的頻率設定了上限。如果 API 用戶端超過允許的要求數，限速將在一段時間內捨棄或封鎖來自它們的更多要求。
DDoS 緩解有助於阻止 DoS 和 DDoS 攻擊。在 DDoS 攻擊中，攻擊者試圖在短時間內用大量要求淹沒 API。這些要求通常來自多個不同的來源。
限速和 DDoS 緩解對於 API 至關重要，原因如下：
要使漏洞利用起作用，惡意 API 要求的結構必須使 API 以其架構師意想不到的方式進行回應。API 開發人員可以透過多種方式封鎖此類惡意要求，其中最重要的兩種方式為：
API 的結構描述指定了 API 的預期行為：它應該獲得的要求類型和它應該提供的回應類型。不符合此結構描述的無效要求可能會導致 API 以意想不到的方式行事，從而可能導致資料洩漏。結構描述驗證可識別無效要求和回應。透過封鎖無效回應，API 開發人員可以避免某些類型的攻擊並協助防止資料洩露。
WAF 的運作方式與傳統的防火牆相似，因為它會封鎖一些網路要求和回應，並允許其他要求和回應通過。它根據一組規則來做這件事：如果一個要求或回應違反了某個規則或符合某個規則，則會被封鎖。WAF 被部署在 API 或 Web 應用程式前面，並監控 HTTP 流量。
可以設定 WAF 規則，封鎖針對某個漏洞的要求和回應模式。WAF 規則還可以封鎖來自某些 IP 位址的要求，這有助於阻止機器人攻擊和其他攻擊者。
驗證可確保 API 要求來自合法來源。授權可讓 API 伺服器知道要求的用戶端是否被授權獲取要求的資料。
假設 Alice 構建了一個 API，而 Bob 構建了一個使用 Alice 的 API 的 Web 應用程式。當 Bob 的應用程式向 Alice 的 API 傳送 API 要求時，他會在要求中附加一個標籤，上面寫著「這來自 Bob」。這會驗證 Bob 的要求，以便 Alice 的 API 伺服器知道將該要求視為合法。
Alice 的 API 伺服器還會檢查 Bob 擁有的權限。如果 Bob 的要求是針對 Alice 的 API 已標記為「Bob 可以看到」的資料，則伺服器會滿足該要求。但是，Alice 的 API 可能有一段資料標記為「不給 Bob 看到」，且當 Bob 是要求者時，伺服器不應滿足對該資料的要求。這就是為什麼授權很重要。
（實際上，Bob 會在 API 要求中附加一個金鑰或某種其他形式的驗證，而不僅僅是一個標明「這來自 Bob」的標籤。）
API 有多種驗證方法。最常見的是：
向用戶端分配一個金鑰——即只有它們和 API 服務知道的一個唯一字串。金鑰附加到每個 API 要求。API 伺服器在收到 API 要求時會檢查金鑰，以確保它來自經過驗證的用戶端。
這種驗證方法的缺點是，如果金鑰被盜，攻擊者可以使用它來冒充合法用戶端，然後可以進行各種攻擊。使用 Transport Layer Security (TLS) 等加密通訊協定對 API 的要求和回應進行加密非常重要——這樣，金鑰在通過網際網路時不會以純文字形式公開。
API 要求可以使用典型的使用者名稱和密碼認證透過一種稱為 HTTP 驗證的方法進行驗證。在 HTTP 驗證中，使用者名稱和密碼被編碼並新增到所有 API 要求的 HTTP 標頭中。伺服器可以檢查這些認證是否為所允許用戶端的認證，從而對要求進行驗證。
這種方法帶來了通常與密碼相關的所有挑戰：密碼可能會丟失、洩露、被盜、被猜到或與不受信任方分享。密碼也容易受到憑證填充和暴力密碼破解嘗試等的影響。
API 伺服器不需要直接從用戶端進行驗證，而是可以使用 OAuth 通訊協定從受信任的驗證伺服器獲取驗證權杖。要使用 API，使用者需要登入第三方服務，而不是直接登入 API。與使用者名稱和密碼方法一樣，這種驗證方法容易受到認證填充和其他攻擊。
TLS 是一種加密通訊協定，它在載入網頁時在用戶端和伺服器之間建立一個加密的、經過驗證的連線。TLS 還可以驗證 API 連線的兩端。
在 mutual TLS (mTLS) 中，用戶端和伺服器都有一個 TLS 憑證。它們使用這些憑證相互驗證，確保兩者都是它們聲稱的身分，而無需依賴密碼或其他驗證方法。
然而，mTLS 的實作可能是一個挑戰：所有 API 端點和用戶端都需要合法的 TLS 憑證，這可能難以執行和維護。
Cloudflare API Shield 從一個儀表板啟用多種 API 安全功能，以防止常見的 API 安全風險。API Shield 包括：
深入瞭解 API Shield 或 API 安全性解決方案。
API 安全性是保護 API 免受攻擊和資料外洩的過程。它確保只有目標使用者才能透過 API 存取特定的服務和資料，並在遭受旨在壓垮 API 或使其離線的攻擊時，保持 API 的正常運作。限速、DDoS 緩解、WAF 規則、結構描述驗證以及強大的驗證做法都有助於保護 API。
驗證會檢查 API 使用者的身分，而授權會決定這些使用者可以存取哪些資料或服務。它們共同協助防止未經授權的資料存取。
常見的 API 安全風險包括漏洞利用、基於驗證的攻擊、授權錯誤和阻斷服務 (DoS/DDoS) 攻擊，這些攻擊可能會中斷合法使用者的 API 服務。
限速限制某人在設定的時間段內可以使用 API 的次數，而 DDoS 緩解有助於吸收或封鎖大量惡意請求。兩者都有助於保持 API 對授權使用者的可用性。
結構描述驗證會封鎖不符合 API 預期格式的請求。這降低了 API 在回應使用者請求時出現意外行為的可能性。WAF 使用規則在惡意或可疑 API 呼叫到達 API 之前予以攔截。
API 使用 API 金鑰、使用者名稱/密碼組合、OAuth 權杖或 mutual TLS (mTLS) 來驗證其使用者。
OWASP API 安全性十大風險提供了安全指南和常見 API 漏洞清單，幫助 API 開發人員瞭解並解決最關鍵的安全風險。
Transport Layer Security (TLS) 等加密通訊協定可以保護傳輸中的 API 資料，防止攻擊者竊取認證或敏感性資訊。如果 API 發出 API 金鑰進行驗證，則該通訊協定尤其重要——如果金鑰在傳輸過程中未加密，攻擊者可以複製並使用它來存取機密資料。此外，有時也會使用 mutual TLS (mTLS) 進行驗證，以阻止攻擊者冒充合法使用者。
零時差威脅是利用 API 中以前未知漏洞的攻擊。零時差威脅尤其難以偵測和阻止。