???

作者丨Artem Arzamas

譯者丨陳峻

策劃丨孫淑娟

【51CTO.com快譯】本文簡單回顧了 API 的發展歷史，其基本概念、功能、相關協議、以及使用場景，重點討論了與之相關的不同安全要素、威脅、認證方法、以及十二項優秀實踐。

根據有記錄的歷史，隨著 Salesforce 的銷售自動化解決方案的推出，首個 Web API 在 1990 年底出現了。在那個時候，它是一種每個人都可以訪問到的開放資源。Salesforce 的自動化工具由 XML 驅動。而用于交換該工具信息的數據格式，后來被公認為 SOAP API 標準。它擁有與允許或禁止各種請求相關聯的消息格式規范、以及特定于代碼的規則。也就是說，大多數開發人員除了需要針對 API 的開發和創建進行必要的 SOAP 處理，也需要手動將 XML 文檔與 RPC 協同使用。之后，開發人員還需要解釋 API 的端點，并將 SOAP 套件發布到該端點處。這不僅是 API 的誕生，也算是 SaaS 概念的開始。

而塑造現代 API 的關鍵事件，離不開 Flicker 和 Facebook API 的推出。Flicker 開發了一個通過云端存儲數字圖像的平臺，該平臺通過開發 API，支持橫跨不同平臺的圖像共享，并集成了各種照片共享設施的新型服務。

到了 2008 年，API 進化成為可以獨立操作，并能夠處理大量互連的信息。Twilio 通過推出一個 API，可方便用戶連接電話、短信等整個產品所需各個部分。

什么是 API?

對于初學者來說，API 是指為兩個不同的應用之間實現流暢通信，而設計的應用程序編程接口。它通常被稱為應用程序的“中間人”。由于我們需要保護用戶的持有數據、以及應用本身的完整性，因此 API 的安全性是一種“剛需”。

而對于開發人員而言，API 是一個非常好的工具。它可以在微服務和容器之間交換信息，并實現快節奏的通信交流。正如集成和互連對于應用開發的重要性那樣，API 在某種程度上，驅動并增強了應用程序的設計。

???

API 風靡互聯網

在互聯網的早期，API 作為專有協議，在網絡中往往被用于受限的區域、目的或組織，讓不同網絡架構的通信與計算成為可能。當 Web 2.0 出現后，基于 Web 的工具廣泛涌現，人們開始使用 REST (REpresentational State Transfer Framework)這一社區開發規范，來構建實際應用的 API 接口，例如我們常見的 OpenAPI。

在如今的 Web 3.0 時代，API 在 IoT 和 AI 驅動的設備之間的通信中，發揮著至關重要的作用。API 的常規請求 - 響應范式也轉變成為了事件驅動的方式。

API 用例

API 作為方便信息交換的基本元素，被廣泛用于 Web 應用程序的開發領域。目前，業界最常使用且最為重要的 API 用例，有如下類型：

單頁應用程序(SPA)

REST API 不但可以加速單頁應用程序的開發，而且能夠協助應用將所有內容放在一張頁面上，以提供完整的用戶體驗。在應用的開發過程中，程序員可以使用預定義的 CSS、JavaScript 和 HTML 文件，來啟動 Web 服務器間的通信。注意，REST 框架通常被用于服務器端的通信，以及針對特定類型框架的客戶端信息交換。

常被用于 SPA 開發的 REST API 框架包括：NancyFx、Express.js 和 ASP.Net WebAPI。作為無狀態的框架，REST API 不會受到客戶端為每個請求去調用一到多個服務器的困擾。因此使用 REST API 進行 SPA 開發，能夠提高應用的可擴展性。顯然，這不但減輕了開發者為擴展應用程序而付出的成本，并且消除了應用對于訪問特定資源的需求。

在 SPA 開發中，除了 REST API 文檔之外，沒有其他元素會被綁定到客戶端和服務器上。因此，這種獨立性促進了應用在開發、測試和部署環節的靈活性。而這恰恰是動態網頁框架所無法達到的。

公共 API、企業級的 B2B

長期以來，電話、傳真和電子郵件一直是 B2B 運營的主要通信手段。然而，為了滿足基于物聯網的信息交換的需求，RESTful API 可以在自動化的企業級 B2B 通信方面，發揮關鍵性的作用。

從客戶的角度來看，發布公共 API 會使得企業能夠創建面向消費者的應用程序，并且最大化與外界的通信交流效果。同時，由于公共 API 允許 B2B 客戶端擴展各種基于用戶的行為，因此它使得業務流程得以充分解耦，并在不增加成本負擔的前提下，增強了基于機器(machine-based)的互操作性。

私有 API 與內部 API 服務

使用私有 API，B2B 客戶可以縮短面市的時間，并在加速啟用新的應用和工具的同時，不會對現有工作流程造成瓶頸。在管理內部工作流時，私有 API 可以為企業找出需要重組和現代化改造的可組合(composable)領域。而作為一個創造性的過程，可組合的業務模型可以將復雜的功能分解為，易于處理的微型部分。私有 API 通過支持內部各個級別的高效通信，促進了資源的戰略性使用。

由于內部 API 提供了針對各種可能導致操作性故障，以及提高系統部件響應時間的詳細信息，因此它使得商業智能分析的結果更加精準。而且在使用私有 API 后，應用的協作和信息交換能力也會變得更加快速且安全。

服務網格

作為基礎設施層的組件，服務網格具有高度的可配置性和低延遲性。通常，它被用于在網絡結構中，處理大規模的內部通信。通過合理地使用網格，開發者可以保證各種與容器化和臨時應用相關的快速、安全且可靠的信息交換。

API 可以被用于服務網格中的信息交換。不過當網格的數據平面與通過系統的每個數據包或請求進行聯系時，情況會變得復雜許多。因此，使用通用數據平面(Universal Data Plane)和 xDS 等 API 可以簡化此類工作。它們可以檢查系統的健康狀況，監控其性能、路由各種傳入或傳出請求、以負載共享的方式平衡系統流量，以及通過服務發現的方式，來發現與用戶授權相關的誤操作。

移動后端

作為一種新興的服務交付模型，移動后端通常被用于移動優化方案的開發中。被稱為移動后端即服務(Mobile Backend as a Service，MBaaS)的開發模型，充分給予了開發人員維護服務器和服務器相關工具的自由，其中包括：用戶管理、推送通知和社交登錄插件等組件。

MBaaS 的各個資源會使用靈活的 SDK，去連接 API 的端點。例如，MBaaS 會使用 Flutter、Unity、Iconic 和 React Native 等技術，為 Android 和 iOS 操作系統開發前端應用。同時，MBaaS 平臺的各種 API 能夠為開發人員在工作流管理、通知更新和任務規劃等方面帶來自動化。

此外，這些 API 可以生成一個應用層，以實現在各種系統和所使用的服務之間，進行無縫的信息交換。開發人員也可以為新添加的用戶集群，設計各種基于需求的服務。

物聯網(IoT)

由于物聯網設備需要連接到客戶端、或其他網絡用戶的設備上，以完成信息的交換，因此在使用 API 時，往往難免暴露交換信息。為此，開發人員需要創建足夠安全的、基于上下文的應用，而不可直接使用 UI 與外部進行交互。

REST API 是目前用于物聯網設備真實場景的、最普遍的 API，它通過互聯網協議來進行信息交換。此外，REST API 也允許開發人員實施身份驗證和授權策略。

不同人眼中的 API

API 的多樣性往往會被用于不同的應用場景中，而不同角色的開發者，對于 API 有著不同的認識。

后端開發：

• 框架：一個結構良好的規劃或戰略，它定義了操作和流程的工作方式。
• 規范：一種基于 Swagger 的文檔，可描述 REST 或 OpenAPI 等功能。例如，與 Geo PC 內容相關的某種 GraphQL 模式。
• 數據和業務邏輯：后端開發人員更喜歡在客戶端(例如，移動應用或瀏覽器)之間分離數據和邏輯。這將有利于他們自己的代碼或數據，例如，單頁面應用和移動應用可以使用相同的數據與 API，去處理各種自定義的集成。
• 統一的移動、Web 和集成后端，可以改進和簡化同步的過程。

DevOps：

• 滿足生產環境的規范：例如，如果端點經常返回 502 錯誤的話，您就應該考慮使用 API，來對其進行修復。
• 可擴展性：如果端點需要通過擴展，來解決 504 錯誤的話，您需要找出與此相關的微服務、最佳流程、以及解決問題的方向(例如，針對 GraphQL 的 REST API)。

???

API 的工作原理流程圖

安全：

• 新的協議：如何應對防火墻、掃描儀和其他舊工具停止升級的問題?
• 東 - 西向(East-west，即各個后端應用與數據庫之間，區別于我們常說的南 - 北向)安全：在網絡內缺乏對通信的良好監控。
• 新的安全、網絡或其他 IT 組件的合規性需求。

API 安全的重要性

如前所述，API 與 API 安全是相輔相成的。那些安全性較差的 API，往往容易暴露，且受黑客的攻擊。而由于 API 主要用于交換信息、連接服務和傳輸數據，因此一旦出現數據泄露，就會給企業帶來重大的損失。

API 的各種認證方法

在授予用戶訪問權限之前，我們有必要驗證那些查看或編輯 API 資源的用戶的真實身份，以防止 API 被不恰當地使用。

1、基于主機的認證

該過程通過驗證主機或服務器，以保證只有經過驗證的用戶，才能訪問到部署在服務器上的資源。我們并不需要任何密鑰、或其他方式，來啟動該過程。但是，服務器應該有能力通過實時驗證登錄密鑰，以控制 DNS 欺騙、路由欺騙、以及 IP 欺騙等事件。

在流程和實現方式上，基于主機的認證與 RSA 非常相似。默認情況下，我們可以不必設置任何參數?；谥鳈C的用戶驗證，可以由管理員通過為本地主機創建私鑰、或提取用于本地主機的公鑰來完成。

2、基本認證

這是最直接的 API 身份確認方案之一。由于客戶端發送帶有預構建標頭的 HTTP 請求，因此，該方法使用 HTTP 協議和進程，來請求和驗證用戶名和密碼等憑據。此類檢查往往是在瀏覽器驅動的環境中完成的。

由于能夠得到絕大多數瀏覽器和服務器的支持，因此此類身份認證所使用到的憑據詳細信息，可以明文形式在網絡上共享，或僅使用 base64 進行編碼。它不但能夠在各種代理服務器上運行，而且能夠將訪問權限授予那些并未托管在 IIS 服務器上的資源。由于缺少加密的保護，因此它很容易受到重放等方式的攻擊。

3、OAuth

作為一種可定制的開放式 API 身份驗證技術，OAuth 可以通過驗證用戶身份和定義授權標準，實現應用與服務器、及存儲類 API 的交互。

當有人登錄系統時，它會通過請求令牌的方式，去驗證用戶身份。為此，個人或請求的創建者必須將訪問資源的請求，轉發到身份驗證服務器上。服務器進而會根據驗證的結果，對請求予以接受或拒絕。

相比其他流程，OAuth 更為安全，因此它成為了許多用戶的首選。OAuth 的三個關鍵要素包括 OAuth 提供者(如 Google 和 Facebook)、OAuth 客戶端(指承載信息的網站 / 頁面)、以及所有者(指提出訪問請求的用戶)。

4、OAuth 2.0

作為 OAuth 的更新版本，OAuth 2.0 是一種被廣泛使用的 API 訪問管理協議。其功能包括通過使用 HTTP 服務，來啟動客戶端應用，進而限制 API 客戶端的訪問。GitHub 和 Facebook 都在其關鍵性 HTTP 服務的身份驗證代碼中，使用到了該協議，進而免去了用戶憑據。

OAuth 2.0 的三個關鍵要素分別是：擁有數據的用戶、應用程序和 API 本身。在身份驗證的過程中，該方法可以很容易地解析到使用不同資源的用戶數據。它可以根據驗證目的，被部署到基于 Web、移動及桌面的應用程序與設備中。

5、SAML

安全斷言標記語言(Security Assertion Markup Language，SAML)，是使用單點登錄技術進行身份驗證的標準化 API 流程。它會根據用戶提供的詳細信息來進行驗證。只有完成驗證，用戶才會被授予針對各種應用程序或資源的訪問權限。目前，SAML 2.0 是被普遍使用的版本。它與 ID 非常類似，可以協助完成對于用戶身份的評估。

API 安全意味著什么?

API 安全不僅專注于保護那些直接或間接暴露給用戶的 API，還涉及到節流、速率限制等網絡安全原則，基于身份的安全分析，以及如下關鍵性的安全控制概念：

API 協議

API 可以根據不同的需求，以多種形式和樣式被使用。而不同的使用方式也決定了 API 實施的安全性。

SOAP

簡單對象訪問協議(Simple Object Access Protocol，SOAP)是一種基于 XML 的消息傳遞與通信協議。該協議可以擴展 HTTP，并為 Web 服務提供數據傳輸。使用該協議，我們可以輕松地交換包含著所有內容的文件、或遠程調用過程。與諸如 CORB、DCOM 和 Java RMI 等其他框架的不同之處在于，SOAP 的整個消息都是被寫在 XML 中的，因此它能夠獨立于各種語言。

REST

作為基于 HTTP 協議的 Web 標準架構，REST 針對每個待處理的 HTTP 請求，可以使用四種動詞：GET、POST、PUT 和 DELETE。對于開發人員來說，RESTful 架構是理解 API 功能和行為的最簡單工具之一。它不但能夠使得 API 架構易于維護和擴展，而且方便了內、外部開發人員去訪問 API。

gRPC

作為一個開源的高性能框架，gRPC 改進了老式的遠程過程調用(Remote Procedure Call，RPC)協議。它使用 HTTP/2 這種二進制幀傳輸協議，簡化了客戶端和后端服務之間的通信和消息傳遞過程。

完全輕量級的 gRPC，要比 JSON 快 8 倍以上。它可以通過開源技術協議調用緩沖區，并對結構化的消息采用了一種與平臺無關的序列化格式。在 API 的使用中，開發人員可以通過 gRPC，找出應該調用和評估參數值的各個過程。

Webhook

Webhook 能夠將自動生成的消息，從一個應用程序發送到另一個應用程序。換句話說，它可以在兩個應用之間實時建立、發送、提取更新的通信。

由于 Webhooks 可以包含關鍵信息，并將其傳輸到第三方服務器，因此我們可以通過在 Webhooks 中執行基本的 HTTP 身份驗證、或是 TLS 身份驗證，來保證 API 的相關安全實踐。

WebSocket

WebSocket 是一種雙向通信協議，可以在客戶端和服務器之間提供成熟的雙向通信通道，進而彌補了 HTTP 協議的局限性。

應用客戶端可以使用 WebSocket 來創建 HTTP 連接請求，并發送給服務器。當初始化通信連接被建立之后，客戶端和服務器都可以使用當前的 TCP/IP 連接，根據基本的消息框架協議，傳輸數據與信息。

XML-RPC

XML-RPC 可以通過標準化的通信過程，實現 WordPress 和其他系統之間的相互通信。它使用 HTTP 作為傳輸的手段，使用 XML 作為編碼過程。其工作代碼被存儲在位于網站根目錄的 xmlrpc.php 文件中。作為 WordPress 3.5 版的默認選項，XML-RPC 能夠讓移動應用與基于 Web 的 WordPress 安裝過程，實現無縫的交互。

不過，對于每個訪問請求而言，由于 xmlrpc.php 能夠共享身份驗證的詳細信息，因此它增加了暴力攻擊和 DDoS 攻擊的幾率。對此，我們在采用 XML-RPC 的 API 時，需要增加相關安全實踐。

JSON-RPC

對于新手而言，JSON-RPC 是一種超輕型的 RPC 協議，可用來開發基于以太坊區塊鏈的 API。它采用 JSON(RFC4627)作為基本的數據格式，具有解釋和處理多個數據結構與規則的能力。該協議可以通過相同的套接字被反復使用。

MQTT

MQTT 是 OASIS 認可的消息協議，已被廣泛地用在物聯網設備和工具開發領域，實現了 HTTP 類型的信息交換。由于非常輕巧，因此它可以讓開發人員能夠一次性擴展到數百萬臺設備上。在 API 安全性方面，MQTT 不但能夠協助實現消息加密，而且可以輕松地應用 TLS 和身份驗證。

AMQP

作為一個開放的協議，高級消息隊列協議(Advanced Message Queuing Protocol，AMQP)規定了消息提供者的行為過程，可以被應用到應用層上，創建互操作式的系統。由于是采用二進制實現的，因此該協議不但支持各種面向消息的中間件通信，而且可以確保消息的全面妥投。

XMPP

作為一整套免費的源技術，XMPP 可用于開發多方協作、即時消息、多方聊天、視頻通話、以及輕量級中間件等領域。它的四個關鍵性組件包括：PHP、MySQL、Apache 和 Perl。

CoAP

作為一種由 RFC 7252 定義的 IETF 標準，CoAP 可以被當作標準化的 API 安全協議，來約束物聯網設備上的應用。由于 CoAP 可以支持通過 LPWAN 進行通信，因此它是保護簡單微控制器節點的最佳選擇。CoAP 工作在 TCP/IP 層，并采用 UDP 作為基本的傳輸協議。

云、本地和混合部署中的 API 安全

云服務、集成平臺和 API 網關等技術領域的發展，使得 API 提供商們能夠以多種方式來保護 API。可以說，針對構建 API 所選擇的技術棧類型，會對保護 API 產生直接的影響。例如，一個大型組織可能會使用多個帶有自研 API 的應用程序。而在他們合并各種應用的過程中，可能會造成各種 API 孤島的出現。這些孤島往往就是安全隱患的所在。

???

在異構生態系統中，跨 API 孤島的特定 API 安全基礎架構，可以被配置為 sidecar、sideband 代理，嵌入到云端與本地的部署之間。由于具有高度可移植性，因此此類安全配置可以方便任何面向未來的技術，輕松地傳輸或提取 API。

API 安全層

API 安全層應該是多層次的結構。各個層面各司其職，最大程度地提供安全保護。

API 發現

API 安全的第一層是 API 發現，畢竟如果不知道目標與威脅，何談如何實施保護。如前所述，API 孤島是阻礙安全人員發現 API 的首要問題。由于缺少 API 的可見性，它將直接妨礙 API 訪問權限的管理。

???

影子 API 是 API 可見性的第二大障礙。當 API 作為應用的一部分被開發時，往往只有開發小組成員對其了如指掌，而安全人員對此類“影子 API”的實施細節不得而知。

第三大障礙便是 API 版本控制。在軟件應用的生命周期中，其 API 通常需要不斷地進行迭代。可是新版本的 API 往往不能立刻且全面地替換掉舊的版本。由于用戶端的應用版本不盡相同，因此舊版本的 API 需要根據向后兼容的需求，繼續運行一段時間。然后呢?它們會逐漸離開開發團隊的視野，甚至被遺忘。這一切都是悄然發生的。

因此，API 發現實際上是 API 提供者和攻擊之間的競賽。如果提供者能夠在攻擊者之前發現上述類型的 API，那么他們便可以從 API 網關、負載平衡器、以及直接內聯的網絡流量中提取 API 的流量元數據，并通過專門的引擎，生產有效的 API 列表報告，以便與 API 管理層上的可用 API 目錄進行比較。

API 安全的 OWASP 十大安全威脅

???

API1:2019 對象級別授權的缺陷

通常，API 端點通過發現處理對象的標識符，來獲取訪問控制層面的攻擊。我們需要針對由客戶端提供的信息，進行逐條檢查。

API2:2019 用戶認證的缺陷

攻擊者往往會利用獲取到的令牌、或驗證系統的執行缺陷，來冒充合法用戶，并執行非法操作。

API3:2019 過度的數據暴露

攻擊者可以通過 API 的調用，合法獲取的數據，推斷出某些條目的相關屬性，進而篩選出各種實用的信息。

API4:2019 資源不足和限流

通常，API 不會對被調用的數據進行流量或數量上的限制。而這就給攻擊者留下了發起拒絕服務(DoS)等搶占資源類攻擊的機會。

API5:2019 功能級授權的缺陷

有些 API 在復雜的訪問控制策略上并不完備，甚至帶有授權上的缺陷。這會導致攻擊者可以通過函數調用，獲得其他用戶能夠調用的資源。

API6:2019 批量分配

為了提高效率，以 JSON 方式為用戶提供信息的模型，往往會提供批量分配(Mass Assignment)，而無需根據具體的許可名單，進行合法的屬性篩選。據此，攻擊者可以通過仔細閱讀配套文檔，來推測出對象的屬性、查找到不同的 API 端點、或在請求負載中發掘額外的屬性，進而對它們進行篡改。

API7:2019 安全配置的錯誤

安全配置的錯誤往往源于不完備的默認設計、隨意的編排、開放的分布式存儲、HTTP 標頭的錯配、寬松的跨域資產共享(Cross-Origin asset sharing，CORS)、以及包含著敏感數據的冗長錯誤消息提示等方面。

API8:2019 注入

攻擊者的有害信息可能會騙過輸入檢查，在未經適當檢驗的情況下，利用 SQL 或 NoSQL 的缺陷，執行惡意命令或獲取信息。

API9:2019 資產管理不當

API 通常能夠發現比常規 Web 應用更多的端點，這使得適當地更新配套文檔就顯得格外重要了。對此，我們應當持續完善 API 的相關表格，及時發現那些未被記入的端點。

API10:2019 日志和監控不足

缺乏日志記錄和檢查，加上事件響應能力不足，都會給 API 調用帶來被攻擊的威脅。

滲透測試

開發人員可以考慮使用 Postman 代理的預構建的 API 測試數據，直接與 API 進行通信。通過快速且反復地開展針對 API 的滲透測試，我們可以在降低測試成本的基礎上，獲取詳細的報告。

由于滲透測試需要對目標 API、乃至整個系統都非常熟練，因此我們最好聘請熟練的安全團隊、或使用開源的工具，去模擬針對 API 的攻擊。通過定期且持續的滲透測試，開發人員將能夠及時找到符合 API 保護級別的補救措施。

12 項 API 安全的優秀實踐

由上述討論可知，API 的安全性對于以數據為中心的應用開發來說，是至關重要的。下面讓我們來討論針對 API 的不同類型與階段的安全優秀實踐。

1、使用加密

為了防范破解類的攻擊，我們需要對那些被用在內、外部通信的 API，使用 TLS 加密協議，并部署端到端的加密。

2、API 認證

如前文所述，身份驗證可以確保 API 不會被陌生人所直接使用。同時，通過 API 密鑰或訪問認證，我們可以蹤調 API 資源的調用。當然，此類安全措施也會增加系統的實施難度。

3、充分利用 OAuth 和 OpenID Connect

OAuth 和 OpenID Connect 的結合能夠為 API 的身份驗證和 / 或授權，承擔全部的責任。例如，在授權過程中，API 的消費者和提供者均不直接進行授權操作，而是讓 OAuth 作為委托協議，為 API 添加一個基本的保護層，并在此基礎上讓 OpenID Connect 標準作為額外的身份層，使用 ID 令牌去擴展 OAuth2.0。

4、安全專家

面對多種 API 安全實踐，您也許會犯“選擇困難癥”。此時，經驗豐富的安全專家可以指導您使用合適的防病毒系統、以及 ICAP(Internet Content Adaptation Protocol)服務器，來構建穩固的 API 安全態勢。

5、持續監控、審計和日志記錄

常言道，預防勝過彌補。我們可以在 API 設計之初，就設置好待監控與記錄的指標;而在應用服務的使用過程中，通過適當的儀表板去跟蹤 API 的交互，并及時審查相關記錄與錯誤信息。同時，在后續的調試與版本更新環節，請不要忘記讓所有的 API 都得以同步。

6、僅共享有限的信息

記住，您通過 API 共享出去的信息越少，API 自身的安全性風險就越小。同時，您也應當確保在錯誤消息中，披露的信息盡可能地少。

此外，使用 IP 地址的白名單與黑名單，是限制 API 資源訪問的好方法。它可以保證只有已授權人員或應用，才能有限地訪問 API 資源，并保持接口上關鍵信息的隱藏性。

7、限流和配額保護

請根據后端系統、實際帶寬、以及服務器的運能，合理地限制有限數量的消息，去訪問某些 API，進而能夠有效地防范 DDoS 攻擊的威脅。

8、有效的數據

服務器應當對接受到的所有內容，進行兩次檢查與驗證。任何新增的內容、龐大的數據集、以及由消費端共享來的信息，都應當經過驗證。目前，JSON 和 XML 驗證是兩種被用于檢查參數安全性的最廣泛工具。同時，它們也可以控制 SQL 注入、以及 XML 炸彈等事件。

9、強大的基礎設施

通過實施最新的安全網絡技術、新型服務器與負載平衡軟件，我們可以在基礎設施的層面上保持 API 的安全性，使之能夠抵御大數據量的泄露攻擊。

10、關注 OWASP Top10

通過上文分析，您不難看出，OWASP 羅列和詮釋出的十大 API 漏洞威脅，是一些最常見的攻擊影響方式。它們不但對于 Web 頁面，對于 API 的各種漏洞也具有極強的危害性。因此，我們需要事先做好代碼級的防范工作。

11、使用 API 防火墻

為 API 構建防火墻可以起到兩方面的好處：

• 可用于執行基本的安全檢查，例如：檢查消息的大小、被 SQL 注入的可能性、以及是否可以立即阻斷攻擊。
• 可在局域網內部融入現有的防護體系，協同提高整體安全態勢。

12、部署 API 網關

無論是供內網使用，還是供外網調用，API 所處的環境往往既復雜又危險。因此，為了減輕管理 API 的壓力，我們可以通過部署 API 網關，對 API 的相關流量進行全面的控制、監控和保護。

譯者介紹

陳 峻 (Julian Chen)，51CTO 社區編輯，具有十多年的 IT 項目實施經驗，善于對內外部資源與風險實施管控，專注傳播網絡與信息安全知識與經驗;持續以博文、專題和譯文等形式，分享前沿技術與新知;經常以線上、線下等方式，開展信息安全類培訓與授課。

原文鏈接：https://dzone.com/articles/api-security-beginners-guide

【51CTO譯稿，合作站點轉載請注明原文譯者和出處為51CTO.com】

???