前 14 大 API 安全風險：如何緩解？

API（應用程式介面）已成為讓軟體程式彼此通訊的入口。它們如同數位橋樑，在不同系統之間傳遞資訊。API 在現代軟體中扮演關鍵角色，使應用程式能夠通訊並協同運作。API 安全可保護這些資料連線，避免未經授權的存取與攻擊。良好的 API 安全框架可保護敏感資料、阻擋惡意請求，並僅允許應可存取 API 的對象使用它。隨著企業將更多關鍵服務移轉到線上，這類保護在今日顯得更加重要也就不足為奇了。本文將說明 API 安全風險究竟是什麼。

我們將討論簡單的安全概念、攻擊者使用的常見威脅，以及如何防止這些攻擊。

什麼是 API 安全？

API 安全是指使用各種方法／裝置來保護組織的 API 及其資料，使其免受各種安全威脅的過程。這包括識別誰擁有 API 的授權存取權、保護系統之間傳輸中的資料，以及確保發送至 API 的請求是安全的。

為什麼 API 安全至關重要？

API 安全 可保護敏感的使用者資訊與組織系統。只要 API 是安全的，攻擊者就無法竊取資料或存取系統。當 API 安全運作時，企業信任也能維持不變。許多合規標準也規定 API 必須是安全的，否則擁有這些 API 的組織將被罰款。

API 會連接處理金流、使用者與公司機密的業務系統。如果 API 缺乏良好的安全性，攻擊者就能入侵並取得這些資料。這會讓組織蒙受金錢損失、破壞客戶信任，並引發法律問題。API 攻擊每年持續增加，這使得保護這些端點更加關鍵。

14 大 API 安全風險與緩解措施

API 每天都暴露於眾多安全威脅之下。這些風險從程式碼中的基本錯誤到更複雜的攻擊皆有。了解這些威脅，可讓安全團隊更容易制定適當的防禦措施。讓我們來看看一些最常見的 API 安全弱點，以及如何補救它們。

1. 存取控制失效

失效的存取控制 會讓使用者讀取或修改超出其預期存取範圍的資源。最簡單的例子是，攻擊者可能修改 URL 中的 ID，並擷取另一位使用者的資料。當 API 未驗證目前登入的使用者是否有權限檢視或更新所請求的資料時，就會發生這種情況。在某些 API 上，攻擊者甚至可以在完全沒有存取檢查的情況下提升自己的角色或變更設定。

為了修復存取控制失效，組織應先針對每個 API 請求檢查使用者角色。定義誰應該看到哪些資料，並參照資料集的擁有者，以確保該資料可以被顯示。使用與精確使用者權限對齊的對應權杖，並持續進行安全稽核以找出存取控制問題。

2. 驗證失效

當 API 對使用者身分的驗證不夠嚴格時，應用程式就會出現驗證失效。有些 API 會接受弱密碼或永不過期的舊登入權杖。如果驗證機制無法正常運作，攻擊者就能以暴力破解弱密碼，繞過現有的驗證機制，進而竊取使用者資料。

組織應實施強式密碼政策，並在關鍵事件前採用兩步驟登入，以強化驗證。此外，企業應實施在一定時間後過期的登入權杖，並在多次密碼嘗試失敗後鎖定使用者。除此之外，應在每個 API 請求上驗證登入權杖，並監控可能顯示攻擊跡象的異常登入模式。

3. 資料暴露

資料暴露是指組織的 API 回傳了超出必要範圍的資料。這通常包括資料庫欄位、偵錯資料，或錯誤訊息中的系統細節。當只請求特定欄位時，組織可能會遇到問題：回應物件不是回傳預期內容，而是回傳完整的資料物件。攻擊者會利用這些額外資訊進行偵察與後續攻擊。

為避免暴露敏感資料，組織應制定每個 API 應回傳內容的結構描述。回應應移除不必要的細節，而錯誤訊息不應包含任何系統資訊。實施從日誌與回應中清除敏感資訊的機制。

4. 資源限制

當 API 從使用者收到過多請求時，就會發生資源限制問題。攻擊者會利用這點向伺服器發送偽造請求。某些 API 也允許使用者透過單次呼叫請求大型承載資料。這會消耗系統資源，也會讓服務對真正的使用者變慢，甚至失效。

組織應建立以使用者或 IP 為基礎的請求上限來管理資源。對請求實施適當延遲，並將呼叫次數過多的 URL 加入封鎖名單。留意具有異常特徵、類似攻擊型態的請求模式。

5. 注入攻擊

API 在未經額外檢查的情況下信任使用者輸入，會導致注入攻擊。從用戶端角度來看，攻擊者會在看似標準的承載資料（例如註冊表單）中送出隱藏的特殊命令。這類命令／承載資料可能使資料庫洩漏敏感資訊、執行系統命令，甚至變更已儲存的資料。當開發人員未對使用者輸入實施輸入清理與驗證時，就會發生這種情況。

組織應實施驗證檢查，在使用所有輸入資料之前先進行檢查（以防止注入攻擊）。透過封鎖特殊字元（例如「<」和「>」）來防止惡意承載資料。使用安全的方法與資料庫通訊。限制輸入大小，並為每個 API 維護允許的輸入類型清單。

6. 不當的資產管理

隨著開發團隊持續部署新功能與版本，API 會快速演進。這通常會導致多個 API 版本同時執行，而較舊版本則為了向後相容性而持續保持啟用。

開發團隊有時會將測試 API 部署到正式環境中，進而產生額外的安全風險。這些被遺忘、未使用或測試用的 API，通常稱為「shadow APIs」或「zombie APIs」，往往包含過時的程式碼，且缺乏目前的安全控制。它們已知的弱點與過時的安全措施，使其成為攻擊者尋找阻力最小路徑時的首要目標。

更妥善管理組織 API 的一種方式是使用 API Inventory，它會記錄 API 的所有版本及其執行位置。當較新的 API 版本開始正常運作後，應淘汰舊版本。如果 API 是用於測試，請將其保留在測試伺服器上。經常掃描所有 API 端點以找出安全問題。使用工具識別網路中的 hidden/shadow/Zombie APIs。

7. 大量指派

當 API 在未經適當篩選的情況下，自動將用戶端提供的資料繫結到內部物件或資料庫記錄時，就會發生大量指派弱點。當 API 接受資料物件進行更新時，它可能會盲目更新所有相符欄位，包括那些原本不打算讓使用者修改的敏感欄位。攻擊者會藉由在請求中加入這些受限制欄位來利用此問題，進而可能提升權限或操控關鍵系統值。

為了防止大量指派，組織應列出每個 API 可更新的欄位。實施此機制以封鎖不在清單上的欄位。將一般使用者與管理員層級操作的 API 分開。根據使用者權限驗證每個欄位更新。透過使用包含額外欄位的請求測試 API，或導入模糊測試工具來發現問題。

8. 跨來源資源共用

跨來源資源共用（CORS）規則會規範哪些網站可以存取組織的 API。簡單來說，薄弱的 CORS 設定會允許任何網站呼叫其 API。在開發期間，CORS 會被設定為允許所有來源。然而，許多時候，組織之後會忘記變更它。

為了解決 CORS 問題，必須實施明確規則，規定哪些網站被允許使用組織的 API。切勿在正式上線的 API 上設定「全部允許」。驗證 CORS 規則，以確保您的 API 確實受到約束。

9. 缺乏端點保護

不足的端點保護 發生於 API 在各個端點上的安全控制不一致時。雖然組織可能在主要端點上實施了強健的安全檢查，但較深層巢狀或較不顯眼的端點，可能缺乏相同程度的保護。攻擊者會主動尋找安全覆蓋中的缺口，以繞過既有安全控制並取得未經授權的存取權。

組織必須在所有 API 端點上實施一致的安全控制，不論其可見性或網路位置為何。將相同的安全標準套用到每個端點，包括驗證、授權與輸入驗證。定期掃描所有端點，包括位於內部網路中的端點，例如預備與測試環境，以確保安全覆蓋一致。

10. 不當的錯誤處理

如果未妥善處理，錯誤會向攻擊者顯示資料庫細節、伺服器路徑或錯誤傾印。錯誤也可能導致安全檢查無法運作。攻擊者會利用錯誤訊息，深入了解 API，並進一步加以利用。

組織應定義可隱藏系統細節的標準錯誤訊息，以改善錯誤處理。不要將完全相同的錯誤同時傳送給日誌檔與使用者。如果發生錯誤，安全檢查仍應持續運作。為了找出攻擊跡象，組織應定期檢查錯誤日誌。

11. 安全性設定錯誤

如果 API 中的設定被設為預設值，例如將密碼設為 admin123，就會發生安全性設定錯誤。大多數 API 一開始都帶有測試密碼、開放連接埠或其他基本安全規則。為了解決邏輯問題，組織有時會停用安全功能，之後卻忘記重新啟用。另一方面，預設設定也往往會讓權限比必要情況更寬鬆，並加入非必要功能，進而使系統更容易出現問題。

組織應設定安全組態，並變更所有預設密碼與存取規則。停用使用者不需要的不必要 API 功能。根據 API 各部分的需求，為其設定安全規則。定期檢查 API 組態以識別問題。使用可偵測錯誤或缺失安全組態的安全掃描工具。

12. 不安全的相依性

在開發 API 時，常會使用許多第三方程式碼套件以節省時間與資源。這些套件通常早已因存在安全問題而廣為人知。如果 API 底層使用了不安全的套件，攻擊者就能利用已知問題取得未經授權的存取權限。

為了保護相依性安全，組織應在使用所有套件之前先驗證其是否存在安全問題。當套件發布新的安全措施時，應立即安裝更新。組織應使用開源相依性掃描工具（SCA 工具），以便在出現不安全套件時收到警示。

13. 缺乏適當的記錄

不良的 API 記錄 會產生安全盲點，這些盲點可能包含潛在威脅，並削弱組織在事件發生期間對其進行回應的能力。不充分的日誌管理，例如將日誌儲存在無法存取的位置，或無法保護日誌完整性，可能協助攻擊者抹除其痕跡，甚至洩露敏感資訊。

為了建立健全的記錄實務，組織應詳細記錄所有 API 呼叫，包括請求標頭、IP 位址、所使用的驗證方法、回應碼等資訊。這包括使用集中且安全的位置來儲存日誌，並控制誰可以存取每一筆日誌。

14. 弱加密

如果 API 使用弱加密，攻擊者很可能能夠讀取或修改敏感資料。有些組織的 API 使用過時的 加密 類型，而這些類型包含弱點。其他則以純文字傳輸一般資料。即使是強加密，也可能因設定不當而被削弱。毫無疑問，攻擊者會選擇 API 加密中的弱點來存取敏感資料。

為了保護 API 及其處理的敏感資料，組織應依賴強式加密，例如 AES。在傳輸或儲存私人資料時，應進行加密。使用安全指南正確設定加密，並在發布新的安全修補程式時更新加密。

結論

我們在日常生活中都會使用 API，不僅限於安全領域，因為我們會連接到數位世界。隨著駭客尋找新的機會來利用關鍵且隱藏的弱點，API 安全威脅與風險正在上升。API 漏洞可能會劫持系統、導致權限提升，或使服務處於易受攻擊的狀態。有些企業因 API 攻擊而停擺，影響使用者驗證、上線導入及其他流程。像 SentinelOne 這樣的工具可以降低 API 安全風險，並順暢地處理整合。

您可以在攻擊者發現之前，提早識別安全問題。同樣重要的是，應實作最佳 API 安全衛生實務，而不只是依賴安全工具來修補安全缺陷。透過關注這些領域，您可以節省時間、保護使用者資料，並避免危及客戶資料。這將有助於您在不發生嚴重中斷或停止的情況下持續營運業務。