務必定期檢視您的應用程式安全性，因為任何疏忽都可能使您、您的團隊、您的使用者甚至您的伺服器面臨嚴重漏洞風險。請勿因為您認為自己無所不知就忽略此頁面。
我們為剛接觸安全領域的人員收集了一些最佳實務，並為剛接觸 Vue 生態系統的資安專業人員提供了一些見解。當我們透過自己的研究和卓越安全社群的發布內容而意識到風險時，我們將會修訂並擴充本文檔。
Vue 安全風險
使用者輸入與 v-html 的危險
v-html 指令是程式化渲染標記的絕佳方式，但即使是 Vue 文件也帶有 此警告
「在您的網站上動態渲染任意 HTML 可能非常危險，因為它很容易導致 XSS 漏洞。僅在受信任的內容上使用 HTML 插值，切勿在使用者提供的內容上使用。」
如果您不知道這意味著什麼，請快速瀏覽 OWASP 對於 XSS（又稱跨站腳本攻擊） 的說明。
公平地說，這 *確實* 是個好建議，但**請勿**掉以輕心。**務必**像攻擊者一樣思考，他們會創新、社交工程、說謊、網路釣魚和偷竊，以進入您的系統。如果 webpack loader 出現漏洞並以惡意方式更改您的頁面怎麼辦？如果有人發起惡意和不良意圖的 PR 怎麼辦？如果突然第三方 API 發生變更，並且不再發送純文字，而是開始發送相同的結構但內容不同怎麼辦？如果您認為安全的系統結果實際上已被植入後門怎麼辦？如果一位資淺開發人員對程式碼進行了意外且根本上具有威脅性的更改，但未經過適當的審查怎麼辦？（是的，愚蠢有時與不良意圖一樣危險！）重點是，**務必**透過為最壞情況做好準備並強化所有系統來預期意外情況。
務必在您需要採取額外預防措施時使用 v-pre 指令。
vue-i18n
Vue 的準官方國際化套件允許您將 html 儲存在金鑰的值中，並且 可能渲染它們。如果使用者無法修改這些值，您應該沒問題 - 但請確保您信任（亦即審查）翻譯人員！我們的建議（儘管它需要更多工作並且會減慢 HMR）是**務必**使用 模板插值。
eval()
儘管您可能會想使用 eval()，即使您知道自己在做什麼，也**請勿**使用。
Quasar 元件
某些 Quasar 元件和外掛程式可以設定為允許渲染「不安全內容」。這是一個選擇性加入的功能，透過使用 *-html 類型的布林屬性來執行。這些元件將在下方討論。
QSelect
如果您沒有自訂與選單相關的具作用域插槽（即 option 具作用域插槽），**務必**阻止元件在標籤和子標籤中渲染 HTML（透過不透過元件屬性啟用它）。一般來說，這不是使用者提供的資料。如果您要自訂此插槽，則您有責任自行進行清理。
QChat 與 Emoji
QChatMessage 元件預設不會將內容顯示為 HTML。但是您可以啟用它（透過 *-html 屬性），在這種情況下，您應該清理內容。
提示
最近發生了一些漏洞利用（特別是針對較舊的 Android 和 iOS 裝置），其中某些 emoji 和非標準 UTF-8 實際上觸發了行動裝置重新啟動和啟動畫面循環。**務必**考慮在純文字類型的輸入欄位中整合 markdown 解析的開發環境，並在將其傳遞給聊天接收者之前在伺服器端將其渲染為 HTML。
載入中
許多開發人員要求 Loading 外掛程式能夠顯示 HTML，因此預設已啟用此功能，但如果您擔心，**務必**新增 sanitize: true，並且您已移除向量。
通知
預設情況下未啟用使用 HTML 設定 Notify 外掛程式樣式的能力，但如果您設定布林屬性 html: true，則您有責任清理它。
對話框
預設情況下未啟用使用 HTML 設定 Dialog 外掛程式樣式的能力，但如果您設定布林屬性 html: true，則您有責任清理標題和訊息。
QInput
任何允許使用者輸入按鍵、從緩衝區貼上或拖曳檔案的欄位都存在安全風險。我們不會深入探討其中的細節，但請記住，維護安全是您的責任。只有您可以預防服務台火災！
QEditor
此元件允許使用者實際建立 HTML（甚至貼上它）。如果您要儲存此內容並將其顯示給其他使用者，則需要在伺服器端驗證它。在這種情況下，**務必**移除 <script></script> 和 <iframe></iframe>。您可以造訪文件中的 v-html 與雙大括號 範例，以試用 QEditor 元件並查看兩種渲染方法將提供什麼。QEditor 沒有 sanitize 標籤。此外，如果您建立自訂按鈕，則您有責任確保它們的安全。您已被警告。
處理檔案
那麼您如何驗證和清理檔案呢？雖然這有點超出「前端框架」的範圍，但我們知道許多閱讀本文的人員也會將使用者建立的檔案儲存在伺服器上。如果您只是儲存它們（而不以任何方式處理它們），**務必**透過偵測 magic numbers 來驗證檔案是否為適當的類型。**務必**考慮使用 ClamAV 檢查檔案是否具有已知的病毒簽名。
圖片
如果您允許使用者上傳圖片到您的伺服器，您應該知道許多常用的模組僅僅檢查檔案副檔名。 製作一個表面上看起來像是圖片的檔案是很容易的。務必驗證檔案是否如其宣稱的那樣，方法是檢查 magic number，並考慮使用 is-image。雖然您可以在瀏覽器中透過這種方法檢查 magic number，但另一種方法是讓使用者將圖片載入到畫布 (canvas) 中，然後直接從畫布上傳。 Vue-croppa 是一個很棒的前端工具，可以做到這一點。
封存檔
封存檔解壓縮攻擊以進行目錄遍歷是一個真實的安全問題，並且實際上在不解壓縮檔案的情況下是不可能檢測到的。 如果您可以避免接受這種類型的媒體，那就盡量避免。 否則，在 Linux 上務必使用簡潔的 less / lesspipe 和 .lessfilter，透過您的自訂工作流程來預處理這些檔案。
密碼
不要以明文儲存密碼，事實上 - 不要儲存它們。 務必儲存安全雜湊值，並根據使用安全 salt 和適當演算法的方案在記憶體中計算它們。 務必限制密碼的長度（字元的最小和最大數量），但要使上限足夠高，以至於沒有合法使用者會達到。 務必考慮高度安全的應用程式流程來重設密碼，並讓使用者根據他們的偏好進行配置。 每個專案的流程都是獨一無二的，因此我們無法告訴您如何解決這個問題。 然而，這裡有一些不錯的連結
密碼學
- 不要建立您自己的密碼學解決方案
- 不要以明文儲存個人資訊
- 不要建立您自己的密碼學解決方案 （有意重複）
- 不要忽略實作細節的任何方面
- 不要建立您自己的密碼學解決方案 （有意重複）
- 不要使用 MD5 或 SHA1
- 不要建立您自己的密碼學解決方案
要閱讀有關此主題並正確選擇工業級強度解決方案的好地方是 libsodium
發布
提示
如果有人想要變更您的資料庫中的內容或將某些檔案新增到伺服器，並且他們沒有使用 SSH 金鑰，務必驗證並且清理輸入內容。
網站
- 不要使用 http
- 不要在 JWT 中儲存敏感資料
- 務必使用 https / wss
- 務必手動稽核您的憑證
- 務必驗證使用者
- 務必記住 JWT 本身並未加密
- 務必使用 JWE 而不是 JWT，並使用 AES256 CBC + HMAC SHA512
- 務必加倍努力並執行完整的 OWASP 網站稽核
Cordova / Capacitor
- 不要使用 iframes
- 不要為 Android Gingerbread 打包
- 務必簽署您所有的建置版本
- 務必加密所有靜態資料
Cordova 文件頁面詳細介紹了如何保護 Cordova 的安全，雖然它看起來已經過時，但資訊在很大程度上仍然切中要點。
Electron
Electron 是一個非常特殊的案例，因為 XSS 和遠端程式碼注入實際上可能導致最終使用者（甚至開發人員）的裝置完全受損。
- 不要停用
websecurity - 不要啟用遠端程式碼執行
- 務必閱讀我們關於加強 Electron 安全性的指南。
SSR
當您使用 SSR 模式產生專案時，您會獲得一個最簡化的 Express 伺服器。 強化您的環境以保護您的伺服器和使用者是您的責任。 為此，我們提供了一系列重要的標頭 (HEADERS)，您可以考慮並應在您的專案進入生產階段之前選擇性地啟用（請參閱 src-ssr/index.js）。 重要的是要記住，標頭並非萬無一失，因為是否尊重它們取決於瀏覽器供應商 - 例如，如果您的內容安全策略 (Content Security Policy) 使用 sandbox 值，Chrome 會中斷 PDF 檢視功能。
- 不要忘記設定限制性標頭
- 不要認為僅靠標頭就能保護您免受所有攻擊
- 務必閱讀有關 標頭的資訊
環境安全
更加安全意味著要考慮許多事情，您遵守以下準則越多，攻擊足跡就會越小。
營運安全
稽核您的開發系統如何運作
- 不要保留不需要的軟體
- 務必使用佔用空間更小且啟用安全功能的作業系統和發行版（例如 SELinux）
- 務必確保您機器上的所有軟體都是最新的（尤其是 NODE）
- 務必使用密碼管理器
- 務必盡可能在任何地方使用雙重驗證 (2FA)
稽核您的生產環境如何運作
- 不要認為當您受到攻擊時，透過隱晦性來實現安全性會有幫助
- 不要讓不需要的連接埠保持開啟
- 不要假裝容器或 VM 本質上會讓您安全
- 不要停止保持警戒
- 務必關閉伺服器的密碼和 root 存取權限
- 務必使用安全傳輸協定（SSH、HTTPS、SFTP、WSS）
- 務必安裝 fail2ban 和 rkhunter
- 務必定期分析您的日誌
- 務必加密靜態資料
- 務必使用進階媒體類型分析
- 務必使用 ClamAV 來偵測受感染的檔案
- 務必進行定期系統維護
- 務必從允許/可用的類型中移除舊的密碼
- 務必使用 CSP 標頭保護使用者
組織與儲存庫安全
這是每個團隊都應該關注並投入一些想法的事情。 務必考慮誰有權存取您的儲存庫、提交如何合併以及資產如何發布。 這裡有一些需要記住的好事
- 不要將敏感資料放入您的原始碼中
- 不要忽略
yarn audit或npm audit報告 - 不要盲目依賴第三方服務
- 務必在合併到 master 之前要求審查
- 務必要求審查者/程式碼提交者使用雙重驗證 (2FA)
- 務必要求簽署提交
- 務必認真對待 GitHub 安全警告
- 務必進行深入的程式碼審查
- 務必審查關鍵的第三方函式庫，尤其是任何處理真實檔案的函式庫
- 務必釘選關鍵函式庫的版本
- 務必提交套件鎖定檔
- 務必將
.env檔案新增到您的.gitignore中
最後注意事項
安全不是安心，而是一種知識的實際應用，需要警惕和意識。 不要停止關注安全性，不要認為您做得夠多了。 總是有更多您可以進行的事情，總是有新的漏洞需要注意。 但所有安全威脅中最大的威脅是懶惰，所以穿上您的外出鞋，向上捲動頁面，務必閱讀關於 XSS 的 OWASP 連結。 我們不會告訴任何人。