什麼是 API 安全性？

API 安全性是保護應用程式介面 (API) 免受惡意使用或試圖利用 API 來竊取敏感資料或中斷服務的攻擊。API 安全性採用策略、技術和解決方案，以確保只有授權使用者才能存取和使用 API，並確保透過 API 傳輸的資料不會受到未經授權的存取或竄改。

API 安全性說明

由於 API 可作為系統和服務的後端框架，因此保護 API 的安全以保護其傳輸的敏感資料 - 包括存取資訊，例如驗證、授權、輸入驗證和加密，是非常關鍵的。API 安全性指的是設計用來保護這些後端框架，並減少違反存取權限、殭屍攻擊和濫用等攻擊的方法和工具。

常見的 API 攻擊類型

• 拒絕服務 (DoS) 攻擊
• 分散式拒絕服務 (DDoS) 攻擊
• 中間人 (MITM) 攻擊
• 破壞存取控制攻擊
• 注射

成功的 API 攻擊會導致大量資料遺失、私人或個人資訊被竊，以及服務中斷。

API 的定義

API 是應用程式介面的縮寫，由一組定義和協定所組成，可讓軟體元件進行通訊。API 作為軟體系統之間的中介，可讓軟體應用程式或服務共用資料和功能。但 API 不僅提供連線基礎架構。它還規範了允許軟體應用程式進行通訊和互動的方式。API 控制程式之間交換的請求類型、請求的提出方式，以及允許的資料格式。

API 可讓組織與客戶及其他外部使用者分享資料。API 的種類包括用於付款處理、視訊會議、社交媒體、簡訊、醫療或健身監控以及智慧型家庭的 API。API 可以是開放或封閉、公開或私有的，通常符合 REST、SOAP 或 GraphQL 等架構標準。

API 也能讓開發人員獲益，讓他們存取其他應用程式的功能，減輕重複建立新連線基礎架構的需要，甚至了解其基本程式碼或架構。

圖 1：現代應用程式結構

API 安全性為何重要

應用程式無所不在，是商業和社會不可或缺的一部分。幾乎每個應用程式背後都有一個 API，因此 API 安全性已提升至關鍵任務。

API 是大多數雲端原生應用程式的後端框架，包括行動應用程式、Web 應用程式和 SaaS，以及內部、面向合作夥伴和客戶的應用程式。從 API 使用的角度來看，API 管理平台 Postman 在 2022 年的 API 調用量為 11.3 億次 。當然，隨著 API 的興起，潛在的利潤豐厚的攻擊面也誘惑著不良分子。

由於 API 會暴露應用程式邏輯、資源和敏感資料 (包括個人識別資訊 (PII))，因此已成為攻擊者的目標。如果攻擊者能夠存取未受保護的 API，他們可能會擾亂業務、存取或破壞敏感資料，以及竊取財產。

圖 2：利用 API 的現代微服務應用程式

Web 應用程式安全的傳統方法

單一應用程式時代的 Web 應用程式安全性包括在周邊部署 Web 應用程式防火牆 (WAF) ，以截取和檢查 Web 用戶端傳送的 HTTP 流量。當應用程式的潛在風險主要涉及嵌入在標準 HTTP 網頁表單提交或瀏覽器請求中的惡意使用者輸入時，WAF 便可提供並會不斷地提供有效的應用程式安全性。

但 Web 應用程式的本質已從單獨 Web 伺服器託管的單一應用程式，轉變為分佈在主機伺服器群集上的容器化雲端原生應用程式。

現今的開發人員和安全性團隊 - 處理高度分散、雲端原生的微服務架構 - 必須與無周界的網路競爭。現代應用程式會消耗來自廣泛來源的輸入 - 標準 Web 請求、行動裝置 API 呼叫、雲端事件、物聯網裝置遙測通訊、雲端儲存等。

用戶端入站 HTTP 請求（即南北流量）通常是一連串通訊流量中的第一個。在許多情況下，一個入站請求會產生數十個內部 API 呼叫（即東西流量）。如果這些內部 API 呼叫沒有經過適當的檢查和驗證，API 端點就會失去保護。

在周邊檢查輸入並不足以捕捉到危險的有效載荷。內部 API 端點可能會設定錯誤，允許未經授權存取個別微服務，使應用程式邏輯暴露於惡意行動之下。所有 API 端點 (無論是外部或內部) 都必須不斷地受到監控與保護，這點至關重要。

視訊：API 安全性概觀及加強 API 安全性的秘訣

API 攻擊剖析

隨著 組織依賴 API 來推動業務，攻擊者也開始尋找 API 漏洞來加以利用。以行動應用程式為前端，針對電子商務應用程式進行 API 攻擊的範例，說明威脅行為者可以輕易找到取得寶貴資料的途徑。

圖 3：基於 API 攻擊的剖析

步驟 1：透過行動應用程式的逆向工程，攻擊者發現了用於從後端微服務擷取資料的已廢棄 API 端點 URL。

步驟 2：攻擊者注意到向此端點傳送 API 呼叫時，既不需要驗證，也不需要授權。

步驟 3：攻擊者濫用 SQLi 漏洞。API 端點 URL 以數值形式提供唯一的產品識別碼，攻擊者執行一系列自動檢查，發現可利用輸入欄位成功執行 SQLi 攻擊。

步驟 4：攻擊者並沒有濫用此 SQLi 來篡改資料，而是選擇濫用 SQLi 漏洞，並在執行 SQL 資料庫的微服務中執行 shell 指令。shell 指令會下載惡意的可執行檔並執行它。可執行檔是一個 bitcoin 挖礦軟體。

API 安全風險

API 設定錯誤、邏輯缺陷和漏洞會讓應用程式和資料暴露在攻擊者面前。雖然 API 閘道只能看到透過閘道傳送的 API 流量，無法提供內部流量的可視性，但有些組織仍將 API 安全性歸咎於 API 閘道，認為它能提供完整的 API 保護。

安全性團隊需要整個 API 表面的可視性。您無法保護您看不到的東西 - 而您看不到的東西最終會變成發現影子 API 的惡劣行為者未被察覺的活動。

雖然 API 閘道能有效監控 API 和 API 使用情況，但卻無法偵測和阻擋攻擊。API 安全需求除了可視性和風險管理之外，還需要即時防禦惡意攻擊。

OWASP Top 10

開放式 Web 應用程式安全專案 (Open Web Application Security Project，OWASP) 在 2019 年公佈了 十大 API 安全風險 清單，讓大家認識到影響現代 Web 應用程式的 API 安全風險。本清單概述針對 Web API 最常見的攻擊，並包含保護您的 API 免受這些威脅的秘訣。

破壞的物件層級授權

處理物件識別碼的端點經常會被 API 暴露，導致層級存取控制問題，擴大了攻擊面。舉例來說，如果沒有實作適當的授權檢查，攻擊者就可以在 API 呼叫期間取代屬於其他使用者的資源 ID。這種攻擊稱為不安全直接物件參考 (IDOR) 攻擊，可讓攻擊者存取未經授權存取的資源。

使用者驗證失敗

API 認證機制很容易成為攻擊目標，因為它們暴露在所有人面前。實作不佳的驗證機制 (稱為破壞的 API 驗證漏洞) 會為攻擊者提供入口，攻擊者可利用實作上的缺陷假冒授權使用者的身分。

如果繞過業界最佳實務，例如未實作存取標記驗證或在 API 端點 URL 中儲存憑證和金鑰，就可能發生 API 驗證設定錯誤。

過多的資料暴露

暴露的資料越多，風險就越大。在 API 實作期間，開發人員有時會揭露物件屬性，但沒有分項限制，並依賴用戶端在 UI 中顯示之前篩選出不必要的資料。但即使 API 用戶端過濾掉敏感資料，攻擊者仍可利用初始 API 呼叫，並可能取得信用卡號碼、登入憑據和社會安全號碼。

缺乏資源與費率限制

不限制客戶端可呼叫資源數量的 API 很容易因流量超載而被 API 濫用。此類超載會降低 API 伺服器的效能，鎖定合法使用者，甚至可能導致 DoS。API 伺服器超載也會讓 API 暴露於認證漏洞，例如暴力認證。

功能斷層授權

API 開發人員面臨的挑戰之一，就是為不同層級的使用者群組和角色實作存取控制政策的複雜性。管理與一般功能之間的區別模糊不清，造成授權漏洞，攻擊者可利用這些漏洞存取使用者的資源或執行未經授權的管理功能。

質量分配

當客戶提供的資料被綁定到資料模型，而沒有經過白名單過濾，以防止使用者將資料指定到受保護欄位時，就會出現大量指定漏洞。利用此漏洞，攻擊者可透過攔截 API 查詢，並透過猜測物件屬性、閱讀文件和搜尋 API 端點，以獲得如何損害私有 API 資料屬性的提示，進而變更儲存的後端物件屬性，從而存取敏感資料。

安全設定錯誤

安全設定錯誤可能會暴露敏感的使用者資訊和系統詳細資料，並可能導致伺服器受到攻擊。常見原因包括允許的跨原生資源分享 (CORS)、不完整或臨時設定、不正確的 HTTP 標頭或 HTTP 方法、不安全的預設設定、不完整或不正確的設定，以及暴露敏感資訊的冗長錯誤訊息。

注射

API 會受到 SQL 插入、NoSQL 注入和指令注入等注入漏洞的攻擊，當不受信任的資料作為指令或查詢的一部分傳送至解釋器時會發生這些漏洞。攻擊者可以誘騙解釋器執行危險的指令，暴露未經授權的資料以供篡改和竊取。

資產管理不當

API 比傳統 Web 應用程式暴露了更多端點，而追蹤這些端點的強大 API 管理，對於防止濫用暴露的敏感或脆弱 API 端點是非常重要的。例如，被淘汰的 API 端點或除錯端點可能會被攻擊者利用來入侵應用程式。

記錄與監控不足

記錄和監控不足儘管不是直接的威脅，卻會延遲惡意活動的偵測。惡意行為者在黑暗中工作，有充裕的時間提前攻擊，並進入不同的系統以篡改、擷取和破壞資料。根據攻擊研究，偵測持續性威脅可能需要超過 200 天的時間。而在資料外洩之後，如果沒有適當的記錄和監控，組織就會缺乏鑑識資訊來評估損害。

視訊：瞭解 OWASP、AppSec 和 OWASP 十大應用程式安全風險

適用於 SOAP、REST 和 GraphQL 的 API 安全性

SOAP、REST 和 GraphQL 是三種常見的 API 架構模式，而每種 API 架構風格都有不同的安全性考量。

SOAP API 安全性

SOAP（簡單物件存取協定）是在電腦網路實作網路服務時交換結構化資料的協定。SOAP 使用 XML 作為其訊息格式，並可透過各種較低層級的通訊協定傳輸，包括 HTTP 和 SMTP。SOAP API 通常使用傳輸層安全性（如 HTTPS）與訊息層安全性（如 XML 數位簽章與加密）的組合來保護。

SOAP API 安全性涉及處理安全問題的通訊協定擴充。SOAP 遵循 Web Services (WS) 規格，透過 WS-ReliableMessaging 等擴充內建錯誤處理支援的功能，確保所有 Web 服務的企業級安全性。

REST API 安全性

表徵狀態傳輸 API（或稱 REST API）的架構依賴於 JSON 資料傳輸和 HTTP/S 傳輸協定，與其他 API 架構相比，這兩種架構都簡化了 REST API 的開發。RESTful API 使用 HTTP 請求來 POST（建立）、PUT（更新）、GET（讀取）和 DELETE（刪除）資料。

由於缺乏內建的安全佈建，REST API 的安全性取決於 API 的設計。資料傳輸、部署和用戶端互動服務必須包含安全考量。大多數的 RESTful API 都會依賴傳輸層安全性（例如 HTTPS）和記號式驗證。

解決 REST API 安全性問題的常見架構選擇是在 API 閘道後方部署 REST API，然後向用戶端提供此連線選項。儘管如此，API 閘道仍無法抵擋各種安全威脅。

REST vs. SOAP

SOAP 與 RESTful API 支援 HTTP 請求與回應，以及安全套接層 (SSL)，但共通性僅止於此。SOAP API 具備內建的安全功能，本身就是安全的。相較之下，RESTful API 則必須透過實作與架構選擇來確保安全性。

GraphQL API 安全性

GraphQL 是一種開放原始碼的 API 語言，既可描述用戶端如何請求資訊，也可作為運行時間來完成現有資料的查詢。GraphQL 語法可用於開發人員從單一或多個來源提出特定的資料請求。透過 GraphQL，用戶端可以定義請求的資料結構，而伺服器將確保傳回精確的結構。

強制執行 GraphQL API 安全性會帶來與可自訂且彈性的要求相關的挑戰。伺服器可能無法處理複雜的查詢，並可能在過程中不慎執行惡意查詢。

緩解 GraphQL API 安全風險的方法包括節流和設定最大查詢深度，以及查詢超時以防禦大型查詢。

API 安全最佳實務

隨著 API 越來越多地被公開，透過實作最佳實務來最小化攻擊面、修復弱點，以及近乎即時地逮捕惡意活動，以解決資料暴露的風險是非常重要的。

使用安全的驗證和授權方法

確保只有授權使用者才能使用安全的驗證方法存取 API，例如 OAuth2 或 JSON 網路權杖 (JWT)。

實作速率限制

在您的 API 上實作速率限制，以防止暴力攻擊和其他惡意行為。速率限制可限制在指定時間內對 API 提出的請求次數。

使用 HTTPS

API 請求與回應應使用 HTTPS，以確保其加密與安全。這在處理敏感資料時尤其關鍵。

定期執行安全評估

定期評估 API 的安全性，以找出潛在的漏洞。檢閱 API 清單的變更，以偵測新暴露的 API 及其風險概況，包括暴露於敏感資料、暴露於網際網路、 工作負載弱點 和驗證等級。

使用 API 金鑰

API 金鑰是唯一的識別碼，用於識別呼叫 API 的應用程式，並驗證存取的授權。API 金鑰與驗證標記的不同之處在於，它們可識別進行 API 呼叫的應用程式 (或網站)，而非使用該應用程式 (或網站) 的個人。兩者都是重要的安全措施。

遵循 API 金鑰儲存的最佳實務，以避免不必要的呼叫、未授權的存取以及遺失個人資料的潛在資料外洩。

監控您的 API

管理和監控 API 規格、文件、測試案例、流量和指標。封鎖不需要的活動，例如惡意 API 流量和不良殭屍，以協助保護應用程式並降低不必要的成本。

教育團隊有關安全性的最佳作法

及早在 CI/CD 管道 中嵌入安全性，並提供訓練以提升開發人員對安全性風險的認識，例如弱驗證及邏輯漏洞。 實作 DevSecOps 原則，包括安全性團隊與開發團隊之間的合作。

瞭解您的弱點

透過例行檢視 OWASP API 安全十大風險，找出 API 生命週期中的弱點。使用 API 掃描工具和技術來識別每個 API 漏洞，並立即解決以防止被利用。

需要安全令牌進行驗證

需求安全令牌進行驗證是第一道防線。安全令牌可在使用者的令牌驗證失敗時拒絕 API 呼叫，從而保護 API 免遭未經授權的存取。

簡而言之，最佳實務應該從攻擊面的可視性與監控開始，可自動發現環境中的所有 Web 應用程式與 API 端點。防禦層應包括南北向和東西向流量的政策，以阻止惡意威脅，不論這些威脅是源自網際網路或您的應用程式內部。

增加另一層的弱點與合規性掃描，加上強大的驗證功能，將可進一步保護您的應用程式。您還需要確保工作負載或基礎架構層的安全性，例如主機、虛擬機器、容器和協助託管應用程式的無伺服器功能。

Prisma Cloud 的 API 安全解決方案

Prisma Cloud 為所有 API 提供完整的 API 發現、風險剖析和即時防護，是其全面雲端原生應用程式防護平台 (CNAPP)的一部分。

API 安全能力

• API 發現：自動搜尋環境中的所有 API，並消除影子或惡意 API 所造成的盲點。
• API 風險分析：識別 API 風險和風險因素（例如設定錯誤、暴露於敏感資料和存取控制），並優先進行修復。
• 即時防護：針對 API、速率限制和惡意殭屍的 OWASP Top 10 攻擊強制執行即時保護。

API 安全常見問題