Web安全是前端開發人員經常忽略的主題。當我們評估網站的質量時，我們通常會查看性能，SEO友好性和可訪問性等指標，而網站抵御惡意攻擊的能力卻常常被忽略。即使敏感的用戶數據存儲在服務器端，后端開發人員也必須采取重要措施來保護服務器，但最終，保護數據的責任在后端和前端之間共享。雖然敏感數據可能被安全地鎖在后端倉庫中，但前端掌握著前門的鑰匙，竊取它們通常是獲得訪問權限的最簡單方法。

[[323821]]

后端和前端之間共同承擔保護用戶數據的責任

惡意用戶可以采取多種攻擊手段來破壞我們的前端應用程序，但是幸運的是，我們只需使用幾個正確配置的響應頭并遵循良好的開發實踐，就可以在很大程度上減輕此類攻擊的風險。在本文中，我將介紹10種簡單的操作，可以通過這些簡單的操作來改善對Web應用程序的保護。

測量結果

在我們開始改善網站安全性之前，重要的一點是要對我們所做更改的有效性提供反饋。雖然量化構成“良好開發實踐”的內容可能比較困難，但是可以相當準確地度量安全頭的強度。就像我們使用Lighthouse獲取性能，SEO和可訪問性分數一樣，我們可以使用 SecurityHeaders.com根據當前響應頭獲取安全分數。

SecurityHeaders可以給我們的最高分是“A+”，我們應該始終為此努力。

關于響應頭的說明

處理響應頭曾經是后端的任務，但是如今，我們經常將Web應用程序部署到Zeit或Netlify等“無服務器”云平臺，并配置它們以返回正確的響應標頭成為前端責任。確保了解你的云托管提供商如何使用響應頭，并進行相應配置。

下面來看一下具體的安全措施有哪些。

1. 使用強大的內容安全策略

完善的內容安全策略(CSP)是前端應用程序安全的基石。CSP是瀏覽器中引入的一種標準，用于檢測和緩解某些類型的代碼注入攻擊，包括跨站點腳本(XSS)和點擊劫持。

強CSP可以禁用可能有害的內聯代碼執行，并限制加載外部資源的域。可以通過將 Content-Security-Policy頭設置為以分號分隔的指令列表來啟用CSP。如果你的網站不需要訪問任何外部資源，一個良好的頭的起始值可能是這樣的：

Content-Security-Policy: default-src 'none'; script-src 'self'; img-src 'self'; style-src 'self'; connect-src 'self'; 

在這里，我們將script-src、img-src、style-src 和 connect-src 指令設置為 self，以指示所有腳本、圖像、樣式表和fetch調用都應該被限制在HTML文檔提供服務的同一來源。其他任何未明確提及的CSP指令將回退到 default-src 指令指定的值。我們將其設置為 none 表示默認行為是拒絕任何URL的連接。

然而，如今幾乎任何web應用程序都不是獨立的，所以你可能要調整這個頭，以便你可以使用其他信任域，如域名Google Fonts或AWS S3 bucket，但始終最好從以下開始最嚴格的政策，并在需要時稍后放寬。

您可以在MDN網站上找到CSP指令的完整列表。

2. 啟用XSS保護模式

如果用戶輸入確實注入了惡意代碼，我們可以通過提供 "X-XSS-Protection": "1; mode = block" 頭指令來指示瀏覽器阻止響應。

盡管大多數現代瀏覽器默認情況下都啟用了XSS保護模式，并且我們也可以使用內容安全策略來禁用內聯JavaScript，但仍建議包含 X-XSS-Protection頭，以確保不使用內聯JavaScript的舊版瀏覽器具有更好的安全性。

3. 禁用iframe嵌入以防止點擊劫持攻擊

點擊劫持是一種攻擊，網站A上的用戶被誘騙對網站B執行某些操作。為了實現這一點，惡意用戶將網站B嵌入到一個不可見的iframe中，然后將iframe放置在網站A上毫無防備的用戶的光標之下，因此當用戶單擊，或者更確切地說，認為他們單擊了網站A上的元素時，他們實際上是單擊了網站B上的某個東西。

我們可以通過提供 X-Frame-Options 響應頭來防止此類攻擊，該響應頭禁止在框架中呈現網站：

"X-Frame-Options": "DENY" 

另外，我們可以使用frame-ancestors CSP指令，該指令可以更好地控制父級可以或不能將頁面嵌入iframe的程度。

4. 限制對瀏覽器功能和API的訪問

良好的安全做法的一部分是，限制對正確使用我們的網站所不需要的任何內容的訪問。我們已經使用CSP應用了這個原則來限制網站可以連接的域的數量，但是它也可以應用到瀏覽器特性上。

我們可以使用 Feature-Policy 頭指示瀏覽器拒絕訪問我們的應用不需要的某些功能和API。

我們將 Feature-Policy 設置為由分號分隔的一串規則，其中每個規則都是功能的名稱，后跟其策略名稱。

"Feature-Policy": "accelerometer 'none'; ambient-light-sensor 'none'; autoplay 'none'; camera 'none'; encrypted-media 'none'; fullscreen 'self'; geolocation 'none'; gyroscope 'none'; magnetometer 'none'; microphone 'none'; midi 'none'; payment 'none'; picture-in-picture 'none'; speaker 'none'; sync-xhr 'none'; usb 'none'; vr 'none';" 

Smashing Magazine上有一篇很棒的文章，詳細介紹了功能策略，但大多數情況下，您希望為所有不使用的特性設置 none。

5. 不要泄露referrer值

當你點擊一個鏈接，從你的網站導航，目的地網站將收到你的網站上最后一個位置的URL在一個 referrer 頭。該URL可能包含敏感數據和半敏感數據(例如會話令牌和用戶ID)，這些數據永遠都不應公開。

為了防止referrer 值泄漏，我們將 Referrer-Policy 標頭設置為 no-referrer ：

"Referrer-Policy": "no-referrer" 

在大多數情況下，這個值應該是不錯的，但是如果您的應用程序邏輯要求您在某些情況下保留 referrer，請查看Scott Helme撰寫的這篇文章，在這篇文章中，他分解了所有可能的頭值以及何時應用它們。

6. 不要根據用戶輸入設置innerHTML值

跨站點腳本攻擊可以通過許多不同的DOM API進行，其中惡意代碼被注入到網站中，但是最常用的是 innerHTML。

我們永遠不應基于用戶未過濾的輸入來設置 innerHTML。用戶可以直接操作的任何值——輸入字段中的文本、URL中的參數或本地存儲項——都應該首先進行轉義和清除。理想情況下，使用textContent而不是innerHTML可以完全避免生成HTML輸出。如果確實需要為用戶提供富文本編輯，請使用專業的第三方庫。

不幸的是，innerHTML 并不是DOM API的唯一弱點，而且容易受到XSS注入攻擊的代碼仍然難以檢測。這就是為什么一定要有一個嚴格的不允許內聯代碼執行的內容安全策略。

7. 使用UI框架

諸如React，Vue和Angular之類的現代UI框架內置了良好的安全性，可以很大程度上消除XSS攻擊的風險。它們自動對HTML輸出進行編碼，減少對XSS敏感DOM API的使用，并為潛在危險的方法(如dangerouslySetInnerHTML)提供明確而謹慎的名稱。

8. 保持你的依賴關系是最新的

快速瀏覽一下 node_modules 文件夾，就會確認我們的web應用程序是由數百(如果不是數千)個依賴項組成的lego拼圖。確保這些依賴項不包含任何已知的安全漏洞對于網站的整體安全非常重要。

確保依賴關系保持安全和最新的最佳方法是使漏洞檢查成為開發過程的一部分。為此，您可以集成Dependabot和Snyk之類的工具，這些工具將為過時或潛在易受攻擊的依賴項創建提取請求，并幫助您更快地應用修補程序。

9. 添加第三方服務前請三思

第三方服務如Google Analytics、Intercom、Mixpanel等，可以為您的業務需求提供“一行代碼”的解決方案。同時，它們會使你的網站更容易受到攻擊，因為如果第三方服務受到損害，那么你的網站也會受到損害。

如果你決定集成第三方服務，請確保設置最強大的CSP策略，該策略仍將允許該服務正常運行。大多數流行的服務都記錄了它們要求的CSP指令，因此請確保遵循其準則。

在使用Google Tag Manager、Segment或任何其他允許組織中任何人集成更多第三方服務的工具時，應該特別注意。有權使用此工具的人員必須了解連接其他服務的安全隱患，并且最好與開發團隊進行討論。

10. 對第三方腳本使用子資源完整性

對于您使用的所有第三方腳本，請確保在可能的情況下包括 integrity 屬性。瀏覽器具有 Subresource Integrity 功能，該功能可以驗證您正在加載的腳本的加密哈希，并確保它未被篡改。

你的 script 標簽如下所示：

<script src="https://example.com/example-framework.js" 
        integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC" 
        crossorigin="anonymous"></script> 

值得說明的是，此技術對第三方庫有用，但對第三方服務的作用較小。大多數情況下，當你為第三方服務添加腳本時，該腳本僅用于加載另一個從屬腳本。無法檢查依賴腳本的完整性，因為可以隨時對其進行修改，因此在這種情況下，我們必須依靠嚴格的內容安全策略。