到目前為止，我們把能用前端指令碼防禦 XSS 的方案都列舉了一遍。
儘管看起來似乎很複雜累贅，不過那些是理論探討而已，在實際中未必要都實現。我們的目標只是為了預警，能發現問題就行，並非要做到滴水不漏的程度。
事實上，HTML5 早已制定了一套瀏覽器 XSS 解決方案 —— Content Security Policy，並且大多主流瀏覽器實現了這個標準。
既然我們使用前端指令碼重新實現一遍，因此得在各個方面佔有優勢。
相容性
CSP 目前主流瀏覽器大多已支援，IE10、11 支援部分功能。對於 IE10 之前的，當然就束手無策了。如果使用前端指令碼實現，可根據瀏覽器的實際能力進退。
對於第一篇介紹的 DOM-XSS，只要支援標準事件模型即可開啟，因此相容 IE9 完全可行。
事實上，IE8 就已開放了瀏覽器 API 介面，並支援原生訪問器的操作。所以，IE8 是支援鉤子程式，並能攔截可疑元素。
考慮到實際中，大多情況不做攔截，僅僅上報日誌用以預警。對於這樣低的需求，任何版本的瀏覽器都是完全可行的，甚至連 IE6 也沒問題。
由於國內 IE 瀏覽器仍佔有相當一部分比例，因此使用前端指令碼的方案，能覆蓋到更廣的使用者群體中。
部署
CSP 是通過 HTTP 頭部實現的，策略配置儲存在 Content-Security-Policy 這個欄位裡，因此得在 Web 伺服器端進行配置。這對一些使用虛擬主機搭建的中小網站來說，配置起來比較麻煩。
而前端實現只需在頁面裡插入個指令碼就行，完全不用關心後端的部署，修改策略也無需重啟服務，維護起來容易的多。
不過，未來 CSP 會支援頁面部署，通過 meta 標籤即可配置策略，因此實用性會大幅提高。
當然，如今面臨的各種問題，最終都能通過標準的完善和時代的進步而消失。所以任何方案都只是在解決當下的問題。
效能
毫無疑問，瀏覽器原生支援的肯定比模擬出來的更有效率。
之前考慮了各種情況，需安裝各種事件和鉤子，感覺很是累贅。不過，那只是理論上防禦最嚴密的情況，現實中基本只作預警，並不需監控全開。
作為測試，我們還是考慮最嚴密的情況。根據前幾篇文章探討的結果，我們做一個原型演示。
為了能線下模擬線上產品，同時做了一個 Chrome 外掛，將指令碼注入到線上頁面裡：
頁面中使用到的指令碼、外掛、網路通訊等，都在控制檯裡監控到，並且根據策略匹配顯示不同的顏色。
再來看效能影響。儘管我們開啟了所有的監控，但初始化消耗的時間，仍可接受。（測試環境 i3 2.3G 的筆記本 Win7 64位）
畢竟，JavaScript 的鉤子僅僅是修改變數的欄位而已，並非像傳統語言那樣得修改記憶體許可權等等。
當然，這個頁面內容比較少，只能看出指令碼初始化的情況。
我們換個內容非常多的頁面：
由於巢狀了框架頁，在討論鉤子的時候我們提到，新的頁面環境也需防禦，因此觸發了多次『主動防禦』的初始化。
『靜態掃描』的內容，正是被 MutationObserver 捕獲的元素。由於頁面內容非常多，靜態元素也是隨著 HTML 文件邊下載邊展現的。儘管掃描累計時間並不少，但相對整個頁面載入的數秒時間，也基本忽略不計了。
『動態掃描』的內容，則是後期通過指令碼建立的。隨著滾動條往下拉，掃描次數也逐漸增多。由於我們勾住了 createElement ，理論上說呼叫會慢一些。不過現實中很少會一口氣大量呼叫該方法的，大多使用模板通過 innerHTML 批量建立。
另外，我們還勾住了 setAttribute 這個常用的方法，統計結果和『訪問器鉤子』一起納入在『屬性檢驗』裡。不過，現實中大多場合並不需要呼叫這個方法，畢竟從 attribute 到 property 還得經過一次字串的解析，能直接用 property 則完全沒必要去 setAttribute。
而訪問器鉤子，只有在修改 script、embed 這些元素的 src 屬性時才會觸發，這些操作本來就很少，因此屬性掃描的額外消耗還是可以忽略的。
策略配置
使用指令碼最大的優勢就在於，其策略可以靈活配置。規則可以動態產生，匹配也不限模式，萬用字元或是正則都可以。本來一切都是指令碼實現的，何去何從完全也可由指令碼決定。
當然，為了更好的適應 CSP 標準，我們儘可能的將策略規範與標準靠近，以便相互相容。
因為指令碼的靈活性，我們不僅支援萬用字元來匹配站點名，正規表示式也是完全支援。同時為了方便測試，除錯控制檯裡可以動態修改策略。
下面，我們找個存在 XSS 的頁面，立即來試驗下：
重新整理，XSS 執行了：
雖然是非同源執行的，但好歹也算個 XSS。我們就那它來測試。
接著開啟我們的防火牆，為可執行模組配上白名單策略。只允許當前站點的資源，其他的則攔截，並且傳送報警日誌：
出現奇蹟的時刻到來了。。。
站外的可疑模組成功攔截了！同時開始傳送預警日誌到後臺。
日誌上報
標準的 CSP 中，上報的格式是固定的，並且資訊內容也有限。但對於指令碼來說，這些都不是問題，隨時可以新增想要獲得的資訊。
你肯定會覺得，上報的數量不會太多，存在漏洞的畢竟只是少數。不過，廣義上的 XSS 未必都是由漏洞引起的。
XSS —— Cross Site Script，只要是頁面裡的站外的指令碼，都可以算是。通常情況下只能由漏洞引起，但在一些特殊的場合，任意頁面都可能出現站外指令碼，例如之前討論的流量劫持，或是瀏覽器外掛，都是很常見的情況。
所以，我們除了能線上預警外，還能統計各個地區執行商的廣告劫持，以及一些網頁外掛外掛。
當然，想繞過也是很容易的。只要在流量上過濾了我們的防禦指令碼，或是遮蔽日誌傳送，我們都是無從得知的。
後記
事實上，最終的方案已上線。儘管只抽樣了極少量的使用者，但仍傳回上百萬的預警日誌。幾乎所有都是廣告劫持和瀏覽器外掛，即使存在漏洞暫時也無法得知，我們不可能一個個去分析復現。因此，我們還需一套高效的復現系統，來幫助我們實現自動化的復現工作。