本指南提供了有關保護基于 HTTP 的 API 的建議。它針對的是負責設計或構建提供 HTTP API 的應用程序的技術人員。請注意，您應該針對您的特定設計進行威脅建模，以完全保護基于 HTTP 的 API。

什么是基于 HTTP 的 API？

基于 HTTP 的 API 可實現不同軟件系統（通常包括第三方服務）之間的通信，并可用于訪問服務和數據庫、操作數據，甚至處理用戶身份驗證和授權。它們是現代互聯網應用程序架構中的關鍵組件。

API（應用程序編程接口）通常定義為一組規范（例如發送到 API 端點的 HTTP 請求的格式）以及響應消息結構的定義，通常為 JSON 格式。API 可用于接收一些數據、上傳一些數據或控制操作或系統。 

API 面臨的威脅

攻擊者可以通過多種方式利用 API 中的弱點和漏洞。例如，他們可以：

• 使用不安全的 API 端點獲取敏感數據
• 使用 API 上傳惡意代碼，并利用它來攻擊系統
• 獲取 API 訪問權限，然后在系統上執行未經授權的操作（例如在銀行系統中進行未經授權的付款）
• 使用 API 來操作已存儲在系統中的數據 
• 通過反復輪詢 API 端點發起拒絕服務攻擊 

由于基于 HTTP 的 API 在您的組織外部共享，目的是提供數據或功能，因此您應該執行特定于服務的威脅建模以了解相關的風險和威脅。

1. 安全開發實踐

您的 API 被入侵可能會影響運營、損害組織的聲譽，甚至可能導致監管機構的罰款。在設計系統之前確定背景非常重要，因為這將確保任何安全控制措施與您面臨的威脅相稱。例如，用于公共天氣預報應用程序的 API 和用于管理生產線的 API 具有完全不同的威脅和風險狀況，這將轉化為不同的安全控制措施

威脅模型你的設計

首先對高級設計進行威脅建模，這樣您就可以在設計過程的早期了解任何潛在威脅。NCSC 關于威脅建模和OSWAP 十大 API威脅的指導可以為您提供幫助。 

使用有據可查的 API

全面的 API 文檔可以為您的 API 設計提供資產管理。這可用于確定：

• 應該作為應用程序的一部分公開的端點 
• 不應暴露的端點（例如開發或管理端點）
• 遺留端點

良好的文檔將有助于確保將正確的安全控制應用于需要它的 API 設計部分。嘗試使用常用的 API 規范（例如OpenAPI）來記錄和描述您的 API。使用社區理解的 API 規范允許使用常用工具來可視化和理解您的 API 設計。

作為本文檔的一部分，請確保您有效地管理 API 版本，以確保不會無意中使用已棄用或不安全的版本，并確保客戶端始終使用最新的安全版本。通過版本控制，您還可以棄用并最終淘汰不安全或過時的 API 版本，從而鼓勵用戶遷移到更新、更安全的版本。

安全開發和測試

NCSC 使用“設計安全”一詞來描述一種開發方法，該方法鼓勵組織將網絡安全“融入”產品生命周期的所有階段，而不是事后才考慮。無論 API 受到多么好的保護，仍然需要安全的開發環境和代碼交付。一旦投入生產，任何 API 都應接受適當的安全測試，包括適用于威脅模型的負面測試和模糊測試（而不僅僅是正面測試）。

使用標準

在構建使用基于 HTTP 的 API 的應用程序時，請嘗試使用眾所周知的適當標準。這可以降低設計中出現安全漏洞的可能性。一些示例包括：

• 使用 JSON 進行數據交換
• 使用 OpenAPI 描述 API 設計
• 使用TLS等標準加密技術來傳輸數據

您的 API 設計中可以考慮許多其他標準，并且您應該優先使用已嘗試和測試的方法，而不是構建自己的方法。

資產登記與治理

資產登記冊和有效治理可以幫助組織保持對其 API 的可見性、控制力和保護。資產登記冊是一份全面的清單，詳細列出了組織基礎設施內的所有 API 端點、服務和相關資源。該登記冊不僅有助于識別潛在漏洞，而且還能在整個生命周期內高效地監控和管理資產。

有效的治理可確保制定政策、程序和控制措施來保護這些資產，并符合行業標準和監管要求。 

2. API 認證與授權

實施強大的身份驗證和授權對于保護 API 至關重要，可確保只有合法用戶或服務才能訪問端點并執行操作。身份驗證可驗證發出 API 請求的實體的身份，而授權可控制經過身份驗證的實體可以執行哪些操作。

在許多情況下，身份驗證和授權是緊密聯系的，某些機制同時發揮這兩種功能。例如，身份提供者頒發的令牌可以對用戶進行身份驗證，并包含定義用戶有權執行哪些操作的聲明。

選擇正確的身份驗證和授權方法需要仔細規劃并考慮應用程序的特定需求。

用戶訪問

應用程序通常需要代表用戶與 API 進行交互，但傳統的用戶身份驗證方法并不適合此目的。與使用用戶憑據相比，更安全的方法是通過身份提供商進行用戶身份驗證。此過程會生成臨時憑據（例如令牌或 Cookie），然后應用程序可以使用這些憑據安全地與 API 進行交互。

有關更多信息，請參閱 NCSC 關于為企業在線服務選擇身份驗證方法和多因素身份驗證的指南

API 身份驗證

安全 API 身份驗證的良好實踐包括以下內容：

安全的生成和交換

憑證應在安全的環境中生成，最好不要從生成憑證的地方導出。對于基于公鑰加密的憑證尤其如此。如果需要導出憑證（通常使用對稱密鑰時），則必須使用安全傳輸來完成，并且該過程應自動化，幾乎不需要人工參與。 

避免將憑證直接硬編碼到存儲在版本控制中的源代碼中，尤其是當存儲庫可公開訪問或廣泛共享時。一旦進入版本控制，機密可能很難完全刪除。攻擊者經常掃描公共存儲庫以查找此類憑證。

安全憑證存儲

確保您的 API 憑據已安全存儲。考慮使用機密管理器（具有安全存儲后端，如 HSM 或云 KMS），或將憑據存儲在防篡改硬件支持的存儲位置（例如 USB 令牌或 TPM）。安全性較差的機密會增加攻擊者竊取您的憑據的可能性，尤其是當您將機密存儲在多個位置時，這會使審計變得困難（此問題稱為“機密蔓延”）。

對于短期憑證（或用于對低價值應用程序進行身份驗證），您可以使用軟件支持的存儲。您應該平衡憑證的有效時間長度、價值和使用的存儲方法。

憑證有效期

憑證的有效期應設置為適合用例和威脅的適當時間。憑證到期后應自動輪換或續訂，輪換過程應自動化，無需人工參與。如果憑證無法存儲在安全的存儲方法中，或者憑證不具有抗重放性，則應通過縮短憑證的有效期來降低風險。 

避免使用長期訪問密鑰，因為如果密鑰被盜用，可能會授予無限期訪問權限，從而可能暴露數據和服務。獲得這些密鑰訪問權限的攻擊者可以濫用您的 API 資源，直到密鑰被輪換或撤銷。使用短期密鑰將縮短攻擊者在密鑰變為非活動狀態（對攻擊者毫無用處）之前可以使用密鑰的時間窗口。

防重放憑證

使用具有防重放保護的憑證。這可以通過使用基于公鑰加密的憑證來實現，例如證書或簽名的 JSON Web 令牌 (JWT)。憑證的使用應成為任何監控策略的一部分，任何濫用行為都應發出警報。

避免使用弱身份驗證方法

不要使用弱身份驗證方法，例如基本身份驗證或 API 密鑰。基本身份驗證以 Base64 編碼格式在每個請求中傳輸用戶名和密碼，而 API 密鑰則放置在 http 標頭中并作為共享承載令牌。這兩種方法都很容易受到攻擊，通常是由于機密管理不善。它們還經常提供廣泛的訪問權限，且不會過期或限制權限。您應該采用更強大的身份驗證方法（例如簽名的 JWT 或證書），這些方法應按照 NCSC 指導實施和管理。 

API 授權

一旦用戶通過身份驗證，控制他們可以執行哪些操作以及他們可以在 API 中訪問哪些數據就很重要了。授權根據請求實體的身份和權限來控制對資源的訪問。除非您托管完全開放的公共 API，否則實施授權框架至關重要。

指導有效授權治理的三個基本原則：

1. 強制執行最小權限：授予用戶或進程執行其任務所需的最低限度的訪問權限，從而限制潛在的安全漏洞或惡意活動。
2. 默認拒絕：默認限制訪問，只允許明確授權的實體進入。
3. 驗證每個請求的權限：持續驗證系統內每個操作的訪問權限。

授予令牌過多權限會增加數據泄露或服務濫用的風險。這通常是由于使用通用密鑰或范圍過廣的令牌，并擁有對各個端點的完全訪問權限所致。 

OpenID Connect 和 OAuth2.0

OAuth 2.0 和 OpenID Connect (OIDC) 是兩個互補的行業標準框架，用于保護 API 訪問和用戶身份管理。您可以使用一系列標準來實現我們的身份驗證和授權指南。

1. OAuth 2.0 是一個授權框架，允許第三方應用程序代表用戶訪問資源，而無需暴露其憑據。它使用令牌促進安全的委托訪問，但本身并不提供身份驗證。 
2. OpenID Connect 通過引入身份層擴展了 OAuth 2.0，該身份層使應用程序能夠通過 JWT 驗證用戶身份并檢索與身份相關的聲明。它通過合并 ID 令牌來實現這一點，該令牌包含有關經過驗證的用戶的已驗證信息。此擴展有助于實現單點登錄 (SSO)，使用戶能夠安全地訪問多個應用程序，而無需重新輸入憑據。

OAuth 的最新進展引入了改進的憑證保護安全機制，例如證書綁定令牌和所有權證明 (DPoP)。盡管這些安全增強功能相對較新，但它們得到了廣泛支持，并被強烈推薦作為OAuth 2.0 最佳當前實踐 (BCP)指南的一部分，以減輕令牌盜竊和重放攻擊等風險。

3. 傳輸中的數據保護

API 數據應使用 TLS（傳輸層安全性）在傳輸過程中受到保護。請參閱NCSC 關于推薦配置文件的指導，以安全地配置 TLS。使用過時的 TLS 協議或弱密碼套件的 API 會使傳輸中的數據暴露給攻擊者，從而可能被攔截和解密。這使得 API 容易受到中間人 (AiTM) 攻擊，從而可能泄露憑據和個人數據等敏感信息。

如果 API 是為小型社區托管的（或者是私有 API），請考慮使用相互認證協議，例如Mutual TLS (mTLS)。這將提供雙向身份驗證，確保客戶端和服務器在建立安全連接之前驗證彼此的身份。如果您確實使用 mTLS，則可能需要為 mTLS 的客戶端身份驗證部分 構建私有 PKI 。

4. 輸入驗證

輸入驗證是在處理 API 收到的數據之前對其進行檢查和驗證的過程。此驗證可確保輸入符合指定的標準（例如數據類型、格式、長度和范圍），并且不含潛在的惡意或意外內容。有關更多信息，請參閱NCSC 安全設計原則中的“使入侵變得困難”部分。

有效的輸入驗證對于防止各種安全漏洞至關重要，包括注入攻擊、數據篡改和拒絕服務 (DoS) 攻擊，這些攻擊可能危及 API 資源的機密性、完整性和可用性。 

您應該盡早驗證輸入，最好是在從外部源接收數據時進行驗證，并確保在每個系統層都進行驗證。層與層之間無意的不一致是造成漏洞的一個眾所周知的原因。在用戶界面層，它有助于盡早發現基本錯誤。應用程序邏輯層強制執行業務規則，確保只有有效數據才能繼續，而數據訪問層則防止注入攻擊并強制執行數據庫約束。在所有層上進行一致的驗證可降低風險并創建更安全的縱深防御架構。  

如果使用 API 網關，它應該執行初始驗證，但不應是唯一的驗證點。實施多層方法，其中網關處理基本檢查，而后端服務執行詳細的、特定于上下文的驗證。為了簡化此過程并確保一致性，請考慮實施中央輸入驗證庫或流程，這樣您就無需為每個功能重新實現驗證邏輯。

句法和語義驗證

輸入驗證應在句法和語義層面進行：

• 語法驗證可確保輸入數據的語法和結構正確，通常側重于預定義的模式、格式和約束。驗證檢查輸入是否符合預期的標準和模式，例如電子郵件地址、電話號碼、日期或貨幣符號的正確格式。
• 語義驗證驗證相關業務環境中數據的正確性（例如確認開始日期早于結束日期，或在預期范圍內）。

通過強制執行語法和語義驗證，開發人員可以拒絕任何不符合指定語法規則且在預期上下文中準確的輸入，從而降低處理錯誤、數據損壞、安全漏洞的風險并提高數據準確性。

語法驗證的良好實踐

JSON 解析器

嚴格的 JSON 解析器可確保數據在語法上正確，驗證其是否符合正確的 JSON 格式。如果輸入數據包含結構錯誤（例如括號不正確或逗號放錯位置），解析器將引發錯誤或異常。

集中驗證庫

使用經過充分測試的輸入驗證庫或框架。這些庫通常提供類型檢查、范圍驗證和清理等功能，減少對復雜且難以維護的正則表達式模式的依賴。

允許列表

允許列表驗證明確定義授權輸入并確保僅接受允許的值。例如，對于來自固定選項（如下拉列表）的結構化數據，應采用數據格式的精確匹配。

架構驗證

JSON 模式可用于定義通過 API 交換的數據結構，并根據這些模式驗證傳入的有效負載。還應使用模式驗證來確保攻擊者不會發送意料之外的額外子句（鍵值對）。 

數據類型驗證器

許多編程語言都提供內置的類型檢查機制。例如，在 Java 或 TypeScript 等靜態類型語言中，編譯器可以強制確保數據類型的正確性。在 Python 或 JavaScript 等動態類型語言中，可以使用庫或自定義函數來執行類型檢查。

最小值和最大值范圍

確保數值參數和日期在指定的最小和最大范圍內，并且字符串符合定義的長度標準。

轉義和編碼

對用戶輸入進行轉義和編碼是一項重要的安全措施，通過將用戶輸入轉換為在應用程序中不具有任何功能意義的格式，確保正確處理特殊字符以防止漏洞（例如 SQL 注入或跨站點腳本）。

5. 緩解 DoS 攻擊

針對 API 的常見攻擊是耗盡 API 可用的資源，這可能導致 DoS 或增加托管 API 的成本。考慮限制或限制 API 的使用速率。“限制”是指對 API 的調用頻率/速度施加配額。這通常以每秒可以發出的請求數來衡量，并且應該允許合法消費者使用量激增。當 API 缺乏速率限制和限制時，它們很容易受到過多請求的影響，從而導致服務器不堪重負，導致拒絕服務 (DoS) 攻擊或資源耗盡。

允許使用量激增是一種很好的做法，因為有時 API 的使用者可能需要發出更多合法請求。您還應該記錄使用者嘗試訪問 API 的次數，以便分析是否存在合法的流量激增，或者您是否受到了潛在的 DoS 攻擊。有關如何理解和緩解 DoS 攻擊的更多信息，請參閱 NCSC 的拒絕服務 (DoS) 指南。  

6. 日志記錄和監控

日志記錄和監控雖然密切相關且經常一起使用，但用途不同。日志記錄是回顧性的，提供全面的審計跟蹤，可用于故障排除、取證分析、合規性審計和事件響應。它側重于存儲信息以供日后審查和分析。另一方面，監控涉及對系統行為、性能指標和安全指標的持續、實時觀察和分析。

允許使用量激增是一種很好的做法，因為有時 API 的使用者可能需要發出更多合法請求。您還應該記錄使用者嘗試訪問 API 的次數，以便分析是否存在合法的流量激增，或者您是否受到了潛在的 DoS 攻擊。有關如何理解和緩解 DoS 攻擊的更多信息，請參閱 NCSC 的為了安全目的需要收集哪些數據以及何時收集。  

日志記錄

日志記錄是對系統內事件、操作和交易的系統記錄。這些日志按時間順序記錄用戶活動、系統更改和數據訪問，從而全面了解 API 的運營狀況。在 API 安全中，日志記錄是保持對 API 生態系統內操作和交互的可見性的重要組成部分。

記錄安全事件

確保日志捕獲重要的安全相關事件，包括身份驗證和授權活動，例如登錄嘗試、權限更改、失敗的請求、錯誤和敏感操作，例如密碼更改、帳戶修改和權限提升。

實施集中日志記錄

如果可能的話，實施一個集中式日志系統來匯總和分析日志，確保來自多個服務和微服務的數據集中在一個地方。

記錄訪問、錯誤和事務日志

跟蹤訪問日志、錯誤日志和交易數據以監控 API 活動并確保安全。記錄每個 API 調用的詳細信息，包括時間戳、源 IP、用戶身份和訪問的端點。這有助于識別未經授權的訪問、跟蹤用戶交互并檢測可能表明潛在安全威脅或欺詐活動的異常交易模式。

保護日志中的敏感數據

絕不應記錄密碼、API 密鑰、訪問令牌和個人身份信息 (PII) 等敏感數據。相反，應使用數據編輯或屏蔽來保護機密信息，并確保日志在靜止和傳輸過程中均經過加密。

監控

監控系統跟蹤關鍵指標，例如 API 響應時間、正常運行時間、資源利用率和安全事件。它們檢測異常、生成警報，并在超出預定義閾值或發現可疑活動時通知管理員或安全團隊。

監控是一種主動預防性措施，旨在發現并解決發生的問題，確保 API 基礎設施持續健康安全。監控在維護 API 的完整性和可用性以及檢測和緩解安全威脅方面發揮著至關重要的作用。

啟用實時監控和警報

使用 SIEM（安全信息和事件管理）工具來監控日志、檢測威脅并啟用異常檢測。設置可疑活動警報，例如多次登錄嘗試失敗（表示潛在的暴力攻擊）或 API 流量激增（可能表示 DoS 攻擊）、日志突然停止（可能表示篡改或正在進行攻擊）或異常/大量數據傳輸（可能表示數據泄露）。確保持續的日志完整性和監控數據移動有助于在安全威脅升級之前檢測和緩解它們。

端點性能跟蹤

實施端點性能跟蹤，重點監控 API 端點的可用性和性能。它跟蹤響應時間、錯誤率和可用性，以確保它們按預期運行，并檢測可能影響 API 可用性或可靠性的任何問題。

7. 限制暴露面

不應過度暴露 API 端點或允許已知的惡意 IP 地址連接到API。限制暴露面，使攻擊者甚至無法訪問 API 的某些敏感部分，這將降低您的應用程序受到攻擊的可能性。 

限制接觸端點

API 端點是客戶端用來連接到 API 的 URL。應該有效管理向客戶公開的 API 端點。除非訪問權限嚴格限制在受信任的網絡（或攻擊者無法控制的設備）內，否則攻擊者可能會擁有一定程度的訪問權限（可能通過反編譯應用等方法來提取 API 端點和密鑰）。

刪除未使用的端點

當 API 更新時，端點有時會暴露在外，尤其是在 API 正在（或已經）停用的情況下。在這種情況下，這可能意味著所有監控和安全功能都將處于非活動狀態，尤其是在不再使用的情況下。這也可能意味著可能存在漏洞的 API 端點暴露在外且可訪問。當 API 端點被棄用時，IT 團隊需要確保端點不再可訪問并且訪問被阻止。第 1 節中提到的資產登記冊將對此有所幫助。  

限制對特權端點的訪問

被視為敏感的端點（例如用于管理 API 的端點）也應具有受限的網絡訪問權限，并且不應公開訪問。這使得攻擊者或惡意用戶更難訪問敏感 API 并試圖利用它。您應該主動掃描您的環境，以確保您知道哪些內容是公開的。這將使您能夠主動發現任何過度暴露的舊版、開發或管理 API。

阻止已知惡意 IP 地址 

阻止已知的惡意 IP 地址以及不應連接到您的 API 的 IP 地址類別的連接。以這種方式阻止 IP 地址通常是許多 Web 應用程序防火墻 (WAF) 中提供的功能。如果可能，您應該嘗試使用托管規則集來阻止 IP 地址，因為這將大大減少您的管理開銷。您需要調整規則集，因此您可能需要在執行規則之前監視規則，以防您最終意外阻止了合法流量。

封閉社區的 API 暴露

如果您托管的是私有 API 或在封閉社區（例如 CNI 部門或政府部門組）中使用的 API，請考慮進一步限制 API 的暴露。這可以采用 mTLS、IP 地址允許列表或使用 VPN 的形式。您將使用哪種方法來減少暴露將取決于封閉社區的規模、威脅和要求。 

API 響應

如果 API 返回過多或不必要的數據，則可能會泄露敏感信息，例如內部標識符、用戶個人標識符 (PII) 或調試詳細信息。此類暴露可能有助于攻擊者收集針對性攻擊的情報，或導致無意中泄露用戶隱私。

API 網關安全

大規模部署 API 時，請使用 API 網關，因為這將提供一致的安全方法。如果您在公共云中托管 API，那么您應該考慮使用云原生基礎設施，而不是將本地解決方案遷移到云中。 

API 網關充當客戶端和后端服務之間的中介，為管理和保護 API 流量提供集中入口點。API 網關的集中特性簡化了大規模構建 API 時安全功能的實現。API 網關可以提供一種方法來提供安全功能的一致實現，因為這些功能是在網關中提供的，而不是后端應用程序代碼中提供的。

您可以在 API 網關中找到的一些安全功能包括：

• 架構驗證（如第 4 節所述）
• 客戶端的身份驗證和授權；API 網關通常支持 OpenID Connect 和 OAuth 2.0 等框架
• 提供一個用于監控和記錄 API 端點的中心點
• 集成到 WAF 和 IDS 等工具中，可以用作縱深防御并限制 API 的暴露