Web 應用程式安全性的漏洞
分散的安全措施如何導致風險
公司 A 和公司 B 的案例
這是公司 A 和公司 B 的案例，他們採用的 Web 應用程式和 API 安全方法看似不同，卻有一個同樣細微但至關重要的瑕疵。這一瑕疵導致二者發生了資料外洩（以及所有關聯的負面結果）。
公司 A 具有最安全的 API 保護。他們會封鎖所有的結構描述違規，限制過多要求的速率，並使用最新的威脅情報將已知的惡意 IP 位址列入封鎖清單。如果將基於密碼的 API 驗證取代為mutual TLS，可能會更安全，但他們從未有過外洩。
但其 API 安全性、威脅情報摘要和 WAF 都來自不同的廠商。並且由於廠商更新，通知 API 安全性的威脅情報不再與保護帳戶登入頁面的 WAF 相容。因此，攻擊者能夠在此頁面上使用新的 SQL 資料隱碼攻擊，並取得合法使用者的使用者名稱和密碼。然後攻擊者會將經過結構描述驗證的要求傳送至其 API，並取得大量的敏感性資料。
與此同時，公司 B 的 Web 應用程式得到充分保護，能夠抵禦 DDoS 攻擊。公司 B 也會向希望與公司 B 的應用程式整合的付費使用者公開 API。
攻擊者會在暗網上購買合法付費使用者的 API 金鑰。有了此金鑰，攻擊者就可以針對公司 B 的 API 伺服器發起低速緩慢的 DDoS 攻擊。攻擊者會啟用一個機器人，以不規則的間隔傳送要求。機器人傳送的每個 API 要求都會被 API 伺服器認為是合法的，因為它帶有可容許的 API 金鑰。遺憾的是，公司 B 的後端團隊忘了透過 DDoS 緩解提供者代理 API 伺服器，即使所有其他伺服器都已受到保護。
隨著要求層層堆積，API 伺服器變得不堪重負，最後根本無法為公司 B 的其他使用者提供服務。很多使用者因為失望而取消了付費帳戶。
公司 A 和 B 有什麼共同的問題？
不同的解決方 案會導致疏忽和漏洞
在這些範例中，兩間公司的 Web 應用程式和 API 安全性方法是多個廠商的解決方案的拼湊組合。這些解決方案沒有整合，也很容易出現手動錯誤。
為了理解這是個問題的原因，請想想 Web 應用程式和 API 安全架構的一般元件：
WAF：封鎖針對 Web 應用程式和 Web 內容的攻擊
機器人管理：負責質詢或封鎖可能的惡意機器人
DDoS 緩解：在面臨任何種類的 DDoS 攻擊（無論是巨流量攻擊還是低量慢速攻擊）時確保 Web 內容在線
API 保護：包括針對 API 進行限速、結構描述驗證、身分驗證等
公司 A 和公司 B 採用了所有這些保護。但由於其 Web 應用程式安全解決方案不同（即便是一流的），存在攻擊者可以利用的瑕疵。
對於公司 A 而言，他們的 WAF 和 API 保護都是分層而非整合的，不得不面臨並封鎖攻擊。一間公司可以阻止的攻擊，可能會攻擊另一間公司。公司 B 的 DDoS 保護並未保護其 API 基礎架構，其傀儡程式管理無法偵測源於機器人的 API 要求，並且其驗證較弱，很容易遭到入侵。
這些只是潛在漏洞的幾個範例。Web 應用程式安全性的其他常見漏洞包括：
有限的威脅情報：威脅情報並非最新、未傳送至正確的位置，或者格式不相容。這是公司 A 的情況。
來自太多來源的太多威脅情報：導致誤判、備援和其他低效的情況。
機器人誤判：這會讓使用者感到沮喪，拖慢服務效率並導致執行不嚴。
警示倦怠：2025 年 Ponemon Institute 的一項研究證實，一般企業平均部署了 45 種不同的安全工具，這與先前的調查結果相符，但仍反映出安全工具數量不斷增加，以及警示倦怠問題日益嚴重。事實上，最新的產業分析指出，許多組織現在使用的安全解決方案已達 60 至 80 種不等，有些甚至管理高達 140 種，這進一步加劇了系統複雜性與管理負擔。
驗證不足：公司 A 和公司 B 都很容易遭受某種形式的認證盜竊。
不可擴展的威脅防禦：硬體網路安全設備會在大型攻擊期間或各種攻擊中造成流量瓶頸，並變得不堪重負。
隨著網路攻擊的複雜性與精巧程度不斷提高，這些安全漏洞所帶來的風險也變得更高。根據 McKinsey 的資料，自 ChatGPT 推出以來，偵測到的網路釣魚網站數量暴增了 138%，其背後推手是生成式 AI 在製作更具說服力的電子郵件與深度偽造技術方面所扮演的角色，這大幅加速了攻擊者的能力提升。
現代攻擊者的行動速度通常比其目標更快，並且改進攻擊策略的速度也更快。
API 所帶來的額外安全風險
API 對現代組織的 Web 應用程式基礎架構越來越重要。如今，Cloudflare 處理的動態流量中有很大一部分是基於 API 的，且這一份額還在持續增長。事實上，許多組織自稱為 API 優先。此外，Cloudflare 封鎖的惡意 API 流量百分比高於 Web 流量，顯示攻擊者已將 API 作為主要目標。
由於 API 經常深度內嵌至 Web 應用程式中，因此，必須高度重視其安全性。然而用心良苦的內部團隊通常會快速部署 API——並且通常不會諮詢安全性。結果是：很多 Web 應用程式漏洞都會追溯至較差的 API 安全性。
TotalEnergies 的一個鮮明例子充分說明了不安全 API 帶來的風險日益增加。2025 年，有缺陷的 API 基礎架構導致資料外洩數量激增 105 倍，從 2024 年僅有的 210,715 筆記錄，激增至超過 2,200 萬筆資料在暗網市場上流通。這樣劇烈的增幅凸顯出能源產業以及所有產業迫切需要將 API 安全視為核心基礎架構，而非事後才考慮的問題。
整合的 Web 應用程式安全解決方案
如果公司 A 和公司 B 將所有 Web 應用程式和 API 安全服務組合到一個整合式平台，而不是使用拼湊的網路安全產品會怎樣？那些不同的服務都可以相互整合嗎？而有關公司基礎架構狀態的資料會出現在單一位置，這樣就可以快速評估攻擊及其安全狀態了嗎？
公司 A 本可以確保所有 Web 應用程式和 API 安全性 架構元件都有最新的威脅情報，並在攻擊開始之前進行阻止——因為攻擊都在一個平台上。公司 B 本可以更輕鬆地將其 DDoS 保護延伸至所有伺服器。
使用一個平台意味著管理更容易，漏洞更少。
這種整合式 Web 應用程式安全性方法需要高度可擴展的基礎架構，以便能夠代理所有類型的流量。在過去的幾十年裡，組織會在需要抵禦新攻擊時或在需要擴大規模時購買設備。但基於雲端的服務可以更輕鬆地擴展，並應能夠代理任何類型的基礎架構。雖然整合式平台並不能保證抵禦所有攻擊，但它肯定會對我們的假定公司有幫助。
不僅僅是個思想實驗：WAAP 變得日益重要
這不僅僅是一個假設性的思想實驗。WAAP（Web 應用程式與 API 保護）平台正迅速成為不可或缺的基礎架構，而不再只是一項理論上的最佳做法。根據 DataHorizzon Research 的資料，全球雲端 WAAP 市場 在 2023 年的估值為 61.2 億美元，並預計從 2023 年至 2032 年間，將以每年 17.8% 的複合年成長率 (CAGR) 持續成長。
這種增長反映了將 WAF、機器人緩解、DDoS 防護和 API 安全性整合到可擴展雲端服務中的需求日益增長，尤其是在 Web 應用程式和 API 在多雲端環境中面臨越來越多複雜威脅的情況下。
WAAP 不僅僅是另一個縮略字：整合 WAF、機器人管理、DDoS 防護、API 安全性和其他服 務對於現代組織而言越來越重要。網際網路的全球化特性使 Web 應用程式和 API 面臨各種各樣且日益複雜的攻擊手段。資料外洩成本持續攀升也就不足為奇了。2023 年，全球平均資料外洩成本攀升至 445 萬美元，其中美國企業承擔的財務負擔最為沉重——每起事件約 948 萬美元。截至 2024 年初，全球資料外洩成本進一步成長至約 488 萬美元——僅一年就成長了 10%。
另一種考量：異構基礎架構
如果公司 A 和公司 B 現在從頭構建應用程式和 API，他們可能會將其整個託管在雲端，可能只需一個託管提供者即可輕鬆部署。但實際上，大多數組織都部署了混合基礎架構，其中包括傳統的內部部署資料庫伺服器、以雲端為基礎的協力廠商 API 以及在多個雲端託管的應用程式服務。這些部署具有多種優勢，但也存在各自的安全性挑戰。
例如，指定雲端提供者產品中的原生安全性可能不會延伸至整個基礎架構。首先，探索並對應其所有基礎架構，然後進行防禦，這可能也是一項挑戰。最後，其網路安全產品可能與技術堆疊中的其他解決方案不相容。
因此，除了整合關鍵 Web 應用程式安全功能以外，WAAP 還需要與基礎架構無關，這意味著它必須能夠領先於任何類型的基礎架構或雲端部署。
與基礎架構無關的整合式 Web 安全性
Cloudflare 採用雲端原生且與基礎架構無關，十多年來一直提供 Web 應用程式安全性，並在單一管理平台內作為一個整合式平台提供所有功能。Cloudflare 還具有觀察大部分網際網路流量的優勢，每秒服務超過 78 百萬個 HTTP 要求，每天平均封鎖 ~1900 億個網路威脅。這為 Cloudflare 提供了洞察零時差威脅和新攻擊的獨特優勢。
Cloudflare 就影響當今技術決策者的最新趨勢和主題發表了一系列文章，本文為其一。
深入探討這個主題。
Gartner 在 2022 年 Gartner® Web 應用程式及 API 保護 (WAAP) Magic Quadrant™ 中將 Cloudflare 評為「領導者」。
重點
閱讀本文後，您將能夠瞭解：
不同的網路安全解決方案如何造成安全性漏洞
這些漏洞表現方式的範例
Gartner 為何建議整合與基礎架構無關的 Web 應用程式安全性平台