單頁應用程式 (SPA) 安全性與網站不同

單頁應用程式 (SPA) 作為數位資料交付和客戶參與的易於開發的介面，正在迅速獲得更強大的立足點。

單頁應用程式（SPA）因其易於開發且能夠提供引人入勝的用戶體驗而變得越來越受歡迎。然而，SPA 也面臨獨特的安全挑戰。在本文中，我們將探討保護 SPA 安全的困難，並討論一種有前途的解決方案，稱為代幣處理程序模式。

傳統網站有一個服務 HTML 和資料的後端。使用者身份驗證通常發生在受網路防火牆保護的後端伺服器上。然而，SPA 透過 API 連接到多個微服務，從而創建了更分散的架構。雖然這種設定為 SPA 提供了輕量級優勢，但它也帶來了重大的安全風險。

主要挑戰之一是用戶身份驗證必須經常在瀏覽器中進行，而不是在網路防火牆後面的受保護伺服器中進行。這使得 SPA 容易受到各種類型的網路攻擊，例如跨站點腳本 (XSS) 憑證盜竊。在這種攻擊方法中，惡意行為者可以將程式碼注入瀏覽器，從而竊取存取權杖和使用者憑證，最終授予他們對有價值的資料和系統的未經授權的存取權限。

另一個挑戰來自於對第三方資料的大量依賴，這些資料通常透過 API 連接到應用程式。大量第三方連線可能會造成雙重問題。

首先，開發人員無法控制其他從業者和組織創建的 API 中內建的安全性。這可能會導致在開發人員不知情的情況下將漏洞引入應用程式。

其次，在這種複雜多樣的環境中編程可能會很乏味，因為涉及大量詳細的、自訂的程式碼和輸入設定。很容易錯過重要的步驟並在不知不覺中造成安全漏洞。此外，隨著環境的發展和適應不斷變化的業務需求，可能會引入隱藏的安全風險。

為了進一步說明這些挑戰，讓我們來比較一下保護網站和 SPA 的設定。

在保護網站安全時，開發人員能夠使用基於 cookie 的會話來授予使用者對 Web 應用程式的存取權。前端網站用戶端在瀏覽器上儲存 cookie，這些 cookie 會隨著每個使用者存取請求傳送到單一後端資料伺服器。授權決策可以基於儲存中保存的會話數據，以便使用者存取在網路防火牆後面保持安全。

此設定對於 SPA 來說是不可能的，因為單頁應用程式沒有專用的後端。內容交付網路 (CDN) 通常透過靜態檔案向 SPA 提供程式碼。這些檔案透過 API 呼叫返回到應用程式。在 SPA 設定中，使用者的會話無法儲存在 cookie 中，因為沒有後端資料儲存。相反，存取令牌可用於代表經過驗證的使用者呼叫 API。

SPA 安全漏洞

SPA 安全性挑戰取決於基於瀏覽器的身份驗證容易受到各種網路攻擊類型的影響。一種威脅類型是跨站點腳本 (XSS) 憑證竊取。在這種攻擊方法中，惡意行為者將能夠竊取存取令牌和使用者憑證的程式碼注入到瀏覽器中，以獲得對有價值的資料和系統的未經授權的存取。

雖然 XSS 是常見漏洞，但它並不是開發人員必須防禦的唯一漏洞。更困難的是，修復一個漏洞往往會帶來新的漏洞，這使得保護 SPA 成為一場永無止境的目標不斷變化的遊戲。例如，使用 OAuth 流透過 OAuth 令牌而不是會話 cookie 來驗證使用者或 API 存取似乎是減輕 XSS 攻擊的好方法。

但是，如果這些令牌儲存在本機儲存中，威脅行為者可以輕鬆存取本機和會話儲存以竊取令牌。如果可以刷新令牌，問題就會加劇，因為即使在使用者會話結束後，攻擊者也可以獲得存取權限。

安全修復可能帶來的意外問題的另一個例子是在內容安全策略 (CSP) 標頭中建立強大的安全策略。雖然這可以添加另一層安全控制，但某些來源可能能夠開啟內容安全性原則並停用它們。

最重要的是，在防禦對資料和系統的未經授權和惡意存取方面，瀏覽器是一個充滿敵意的環境。任何安全措施都需要仔細測試和持續警惕，以確保關閉一種攻擊媒介不會為另一種攻擊媒介開闢道路。

同時使用 Cookie 和令牌

最近開發的用於保護使用者身分驗證免受惡意行為者侵害的 SPA 的一種保護方法是令牌處理程序模式，該模式合併了網站 cookie 安全性和存取權杖。透過實施令牌處理程序架構，從瀏覽器中刪除身份驗證並利用同站點 cookie 和令牌的後端到前端 (BFF) 配置，組織能夠從 SPA 的輕量級方面受益，而無需犧牲安全性。

在此設定中，作為後端元件所託管的 OAuth 代理程式位於 SPA 和授權伺服器之間。 OAuth 代理程式處理 SPA 的 OAuth 流，並且不是向 SPA 頒發令牌，而是頒發僅安全的 HTTP cookie，SPA 可使用該 cookie 來存取其後端 API 和微服務。

託管在高效能 API 閘道中的 OAuth 代理程式

以上是單頁應用程式 (SPA) 安全性與網站不同的詳細內容。更多資訊請關注PHP中文網其他相關文章！