XSS（跨站指令碼攻擊），聊兩句，五毛的。
XSS的危害：
- 竊取Cookie，盜用使用者身份資訊
這玩意兒是大多數XSS的目標，也好解決，可以先治個標，直接設定HttpOnly=true ，即不允許客戶端指令碼訪問，設定完成後，通過js去讀取cookie，你會發現document.cookie 無法讀取到被標識為HttpOnly的Cookie內容了。
- 配合其他漏洞，如CSRF（跨站請求偽造）
這個其實就沒那麼好解決了，因為XSS利用使用者身份構造的請求其實對於服務端來說是合法的。比如說我們在B站上傳了一條視訊，發現沒幾個人點贊，於是動了歪心思，開啟控制檯找到了投幣點讚的介面，然後拿到了對應的請求引數。自己構造了一條投幣請求，然後誘導其他人點選含有這個指令碼的頁面為我們的視訊投幣，這樣就完成了一套攻擊流程。
不用嘗試了，沒用的。別問我怎麼知道的 =。=。
要是沒做校驗的話，那這就是一個高危漏洞，還傳啥視訊啊，趕緊發郵件給阿B領賞金去啊。
- 廣告
只要能發起XSS，我就能往頁面裡插廣告，啥許可權都不要，但是能引發這個問題的原因主要有兩個。
- XSS。
- 使用者自己安裝外部指令碼。
使用外部指令碼一定要保證指令碼來源的可信性，指令碼的安全性。如果指令碼是惡意的，那麼他所能做的可就不只是彈彈廣告這麼簡單了，替換個按鈕，誘導點選釣魚頁面，替換某一條搜尋結果，這都是可能的。
XSS掃描及防範
XSS風險有些是可以通過code review發現的，比如：
let result = document.getElementById('test');
result.innerHTML = await getInfo();
這段程式碼很容易看到風險位置——innerHTML ，如果後端返回的資料中包含惡意的程式碼片段，那麼就能夠被攻擊。所以在使用Vue和React框架時，需要評估是否真的需要使用v-html 和dangerouslySetInnerHTML 功能，在前端的render（渲染）階段就避免innerHTML 和 outerHTML [1]。
如果不使用框架，那就避免直接使用
innerHTML就好了。
至於review時無法發現的風險，那就交給掃描器吧。
防範XSS，除了少使用、不使用innerHTML 外，還可以設定嚴格的CSP[2]，限制使用者的輸入長度。
XSS是一個安全問題，它不只是前端的職責，這也是所有RD和QA的職責。
前端過濾使用者輸入後發給後端，後端如果不做處理存入資料庫，那麼這就是一個攻擊點：直接抓前端的包，重新組裝一下引數，發給後端，完成儲存型XSS第一步，使用者再訪問這部分內容，就完成了一次XSS。
QA的總能搞出來一些奇奇怪怪的payload（亦稱測試用例），這些可能都是RD未能考慮到的方面。
附一段白名單過濾使用者輸入的程式碼，點選GitHub檢視。