作者丨Artem Arzamas
譯者丨陳峻
策劃丨孫淑娟
本文簡單回顧了 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 非常相似。預設情況下，我們可以不必設定任何引數。基於主機的使用者驗證，可以由管理員透過為本地主機建立私鑰、或提取用於本地主機的公鑰來完成。
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