本指南提供了有關(guān)保護(hù)基于 HTTP 的 API 的建議。它針對的是負(fù)責(zé)設(shè)計或構(gòu)建提供 HTTP API 的應(yīng)用程序的技術(shù)人員。請注意，您應(yīng)該針對您的特定設(shè)計進(jìn)行威脅建模，以完全保護(hù)基于 HTTP 的 API。

什么是基于 HTTP 的 API？

基于 HTTP 的 API 可實現(xiàn)不同軟件系統(tǒng)（通常包括第三方服務(wù)）之間的通信，并可用于訪問服務(wù)和數(shù)據(jù)庫、操作數(shù)據(jù)，甚至處理用戶身份驗證和授權(quán)。它們是現(xiàn)代互聯(lián)網(wǎng)應(yīng)用程序架構(gòu)中的關(guān)鍵組件。

API（應(yīng)用程序編程接口）通常定義為一組規(guī)范（例如發(fā)送到 API 端點的 HTTP 請求的格式）以及響應(yīng)消息結(jié)構(gòu)的定義，通常為 JSON 格式。API 可用于接收一些數(shù)據(jù)、上傳一些數(shù)據(jù)或控制操作或系統(tǒng)。 

API 面臨的威脅

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

• 使用不安全的 API 端點獲取敏感數(shù)據(jù)
• 使用 API 上傳惡意代碼，并利用它來攻擊系統(tǒng)
• 獲取 API 訪問權(quán)限，然后在系統(tǒng)上執(zhí)行未經(jīng)授權(quán)的操作（例如在銀行系統(tǒng)中進(jìn)行未經(jīng)授權(quán)的付款）
• 使用 API 來操作已存儲在系統(tǒng)中的數(shù)據(jù) 
• 通過反復(fù)輪詢 API 端點發(fā)起拒絕服務(wù)攻擊 

由于基于 HTTP 的 API 在您的組織外部共享，目的是提供數(shù)據(jù)或功能，因此您應(yīng)該執(zhí)行特定于服務(wù)的威脅建模以了解相關(guān)的風(fēng)險和威脅。

1. 安全開發(fā)實踐

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

威脅模型你的設(shè)計

首先對高級設(shè)計進(jìn)行威脅建模，這樣您就可以在設(shè)計過程的早期了解任何潛在威脅。NCSC 關(guān)于威脅建模和OSWAP 十大 API威脅的指導(dǎo)可以為您提供幫助。 

使用有據(jù)可查的 API

全面的 API 文檔可以為您的 API 設(shè)計提供資產(chǎn)管理。這可用于確定：

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

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

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

安全開發(fā)和測試

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

使用標(biāo)準(zhǔn)

在構(gòu)建使用基于 HTTP 的 API 的應(yīng)用程序時，請嘗試使用眾所周知的適當(dāng)標(biāo)準(zhǔn)。這可以降低設(shè)計中出現(xiàn)安全漏洞的可能性。一些示例包括：

• 使用 JSON 進(jìn)行數(shù)據(jù)交換
• 使用 OpenAPI 描述 API 設(shè)計
• 使用TLS等標(biāo)準(zhǔn)加密技術(shù)來傳輸數(shù)據(jù)

您的 API 設(shè)計中可以考慮許多其他標(biāo)準(zhǔn)，并且您應(yīng)該優(yōu)先使用已嘗試和測試的方法，而不是構(gòu)建自己的方法。

資產(chǎn)登記與治理

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

有效的治理可確保制定政策、程序和控制措施來保護(hù)這些資產(chǎn)，并符合行業(yè)標(biāo)準(zhǔn)和監(jiān)管要求。 

2. API 認(rèn)證與授權(quán)

實施強大的身份驗證和授權(quán)對于保護(hù) API 至關(guān)重要，可確保只有合法用戶或服務(wù)才能訪問端點并執(zhí)行操作。身份驗證可驗證發(fā)出 API 請求的實體的身份，而授權(quán)可控制經(jīng)過身份驗證的實體可以執(zhí)行哪些操作。

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

選擇正確的身份驗證和授權(quán)方法需要仔細(xì)規(guī)劃并考慮應(yīng)用程序的特定需求。

用戶訪問

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

有關(guān)更多信息，請參閱 NCSC 關(guān)于為企業(yè)在線服務(wù)選擇身份驗證方法和多因素身份驗證的指南

API 身份驗證

安全 API 身份驗證的良好實踐包括以下內(nèi)容：

安全的生成和交換

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

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

安全憑證存儲

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

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

憑證有效期

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

避免使用長期訪問密鑰，因為如果密鑰被盜用，可能會授予無限期訪問權(quán)限，從而可能暴露數(shù)據(jù)和服務(wù)。獲得這些密鑰訪問權(quán)限的攻擊者可以濫用您的 API 資源，直到密鑰被輪換或撤銷。使用短期密鑰將縮短攻擊者在密鑰變?yōu)榉腔顒訝顟B(tài)（對攻擊者毫無用處）之前可以使用密鑰的時間窗口。

防重放憑證

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

避免使用弱身份驗證方法

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

API 授權(quán)

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

指導(dǎo)有效授權(quán)治理的三個基本原則：

1. 強制執(zhí)行最小權(quán)限：授予用戶或進(jìn)程執(zhí)行其任務(wù)所需的最低限度的訪問權(quán)限，從而限制潛在的安全漏洞或惡意活動。
2. 默認(rèn)拒絕：默認(rèn)限制訪問，只允許明確授權(quán)的實體進(jìn)入。
3. 驗證每個請求的權(quán)限：持續(xù)驗證系統(tǒng)內(nèi)每個操作的訪問權(quán)限。

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

OpenID Connect 和 OAuth2.0

OAuth 2.0 和 OpenID Connect (OIDC) 是兩個互補的行業(yè)標(biāo)準(zhǔn)框架，用于保護(hù) API 訪問和用戶身份管理。您可以使用一系列標(biāo)準(zhǔn)來實現(xiàn)我們的身份驗證和授權(quán)指南。

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

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

3. 傳輸中的數(shù)據(jù)保護(hù)

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

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

4. 輸入驗證

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

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

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

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

句法和語義驗證

輸入驗證應(yīng)在句法和語義層面進(jìn)行：

• 語法驗證可確保輸入數(shù)據(jù)的語法和結(jié)構(gòu)正確，通常側(cè)重于預(yù)定義的模式、格式和約束。驗證檢查輸入是否符合預(yù)期的標(biāo)準(zhǔn)和模式，例如電子郵件地址、電話號碼、日期或貨幣符號的正確格式。
• 語義驗證驗證相關(guān)業(yè)務(wù)環(huán)境中數(shù)據(jù)的正確性（例如確認(rèn)開始日期早于結(jié)束日期，或在預(yù)期范圍內(nèi)）。

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

語法驗證的良好實踐

JSON 解析器

嚴(yán)格的 JSON 解析器可確保數(shù)據(jù)在語法上正確，驗證其是否符合正確的 JSON 格式。如果輸入數(shù)據(jù)包含結(jié)構(gòu)錯誤（例如括號不正確或逗號放錯位置），解析器將引發(fā)錯誤或異常。

集中驗證庫

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

允許列表

允許列表驗證明確定義授權(quán)輸入并確保僅接受允許的值。例如，對于來自固定選項（如下拉列表）的結(jié)構(gòu)化數(shù)據(jù)，應(yīng)采用數(shù)據(jù)格式的精確匹配。

架構(gòu)驗證

JSON 模式可用于定義通過 API 交換的數(shù)據(jù)結(jié)構(gòu)，并根據(jù)這些模式驗證傳入的有效負(fù)載。還應(yīng)使用模式驗證來確保攻擊者不會發(fā)送意料之外的額外子句（鍵值對）。 

數(shù)據(jù)類型驗證器

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

最小值和最大值范圍

確保數(shù)值參數(shù)和日期在指定的最小和最大范圍內(nèi)，并且字符串符合定義的長度標(biāo)準(zhǔn)。

轉(zhuǎn)義和編碼

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

5. 緩解 DoS 攻擊

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

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

6. 日志記錄和監(jiān)控

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

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

日志記錄

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

記錄安全事件

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

實施集中日志記錄

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

記錄訪問、錯誤和事務(wù)日志

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

保護(hù)日志中的敏感數(shù)據(jù)

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

監(jiān)控

監(jiān)控系統(tǒng)跟蹤關(guān)鍵指標(biāo)，例如 API 響應(yīng)時間、正常運行時間、資源利用率和安全事件。它們檢測異常、生成警報，并在超出預(yù)定義閾值或發(fā)現(xiàn)可疑活動時通知管理員或安全團(tuán)隊。

監(jiān)控是一種主動預(yù)防性措施，旨在發(fā)現(xiàn)并解決發(fā)生的問題，確保 API 基礎(chǔ)設(shè)施持續(xù)健康安全。監(jiān)控在維護(hù) API 的完整性和可用性以及檢測和緩解安全威脅方面發(fā)揮著至關(guān)重要的作用。

啟用實時監(jiān)控和警報

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

端點性能跟蹤

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

7. 限制暴露面

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

限制接觸端點

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

刪除未使用的端點

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

限制對特權(quán)端點的訪問

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

阻止已知惡意 IP 地址 

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

封閉社區(qū)的 API 暴露

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

API 響應(yīng)

如果 API 返回過多或不必要的數(shù)據(jù)，則可能會泄露敏感信息，例如內(nèi)部標(biāo)識符、用戶個人標(biāo)識符 (PII) 或調(diào)試詳細(xì)信息。此類暴露可能有助于攻擊者收集針對性攻擊的情報，或?qū)е聼o意中泄露用戶隱私。

API 網(wǎng)關(guān)安全

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

API 網(wǎng)關(guān)充當(dāng)客戶端和后端服務(wù)之間的中介，為管理和保護(hù) API 流量提供集中入口點。API 網(wǎng)關(guān)的集中特性簡化了大規(guī)模構(gòu)建 API 時安全功能的實現(xiàn)。API 網(wǎng)關(guān)可以提供一種方法來提供安全功能的一致實現(xiàn)，因為這些功能是在網(wǎng)關(guān)中提供的，而不是后端應(yīng)用程序代碼中提供的。

您可以在 API 網(wǎng)關(guān)中找到的一些安全功能包括：

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