老闆知道會點贊，前端開發人員的10個安全建議

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

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

惡意用戶能夠採起多種攻擊手段來破壞咱們的前端應用程序，可是幸運的是，咱們只需使用幾個正確配置的響應頭並遵循良好的開發實踐，就能夠在很大程度上減輕此類攻擊的風險。在本文中，我將介紹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>

值得說明的是，此技術對第三方庫有用，但對第三方服務的做用較小。大多數狀況下，當你爲第三方服務添加腳本時，該腳本僅用於加載另外一個從屬腳本。沒法檢查依賴腳本的完整性，由於能夠隨時對其進行修改，所以在這種狀況下，咱們必須依靠嚴格的內容安全策略。

---

原文：https://levelup.gitconnected.com/10-security-tips-for-frontend-developers-19e3dd9fb069

做者：Konstantin Lebedev

---

若是對你有所啓發和幫助，能夠點個關注、收藏、轉發，也能夠留言討論，這是對做者的最大鼓勵。

做者簡介：Web前端工程師，全棧開發工程師、持續學習者。