說到跨站資源監控，首先會聯想到『Content Security Policy』。既然 CSP 好用，我們何必自己再搞一套呢。那就先來吐槽下 CSP 的缺陷。
目前的 CSP
日誌不詳細
用過 CSP 的都很鬱悶，上報的只有違規的站點名，卻沒有具體路徑。這是缺陷，還是特意的設計？
顯然，CSP 是爲安全定製的，裏面的規範自然要嚴格制定，否則就會帶來新的安全問題。如果支持詳細路徑的上報，那又會引出什麼問題？
由於 CSP 會上報所有的請求，甚至包括重定向的，因此可以用來探測重定向後的地址。假如已登錄的用戶訪問 login.xx.com 會重定向到 xx.com/username，那麼攻擊者設計一個只允許重定向前的規則的頁面，用戶訪問後，重定向後的 URL 就會當做違規地址上報給攻擊者，這其中就包括了用戶名。
如果支持詳細路徑的上報，這簡直就是災難，就用來探測的用戶隱私信息了。事實上目前只上報主機名，都能進行一些利用，例如這篇 Using Content-Security-Policy for Evil。
不過新的規範總是在改進，未來也許只上報重定向前的 URL。但在這之前，我們只能接受這些雞肋的上報日誌。
規則不靈活
CSP 目前只支持白名單列表，這多少有些死板。
更糟的是，不同規則之間無法繼承和共享。例如默認有個 default-src 規則，但其他的規則會覆蓋它，而不是繼承它。這就導致各個規則之間，出現很多的重複，使得整個字符串變的冗長。
無法和頁面交互
CSP 的監控和上報，是在瀏覽器後臺自動處理的，沒有提供一個事件供頁面進行交互。
這樣就只能使用統一方式強制處理了，而無法交給頁面腳本，更好的來自定義處理。
上報方式不可控
如果處理方式有多種選擇，那麼統一處理也無可厚非。
但事實上 CSP 的上報方式及格式，沒有任何可選餘地。只能使用 POST + JSON 的方式提交，並且其中的字段十分累贅，甚至把規則裏的白名單列表也發上來了。
此外，也無法設定一個緩存時間，控制重複上報的間隔。在配置白名單遺漏時，會出現大量的誤報，嚴重消耗資源。
浪費帶寬
在較新的 Chrome 裏，能夠使用 meta 標籤在前端頁面定義 CSP 規則，但其他瀏覽器目前仍不支持。
爲了能夠統一，大多仍使用 HTTP 頭部輸入的方式。由於規則通常都很長，導致每次頁面訪問，都會額外增加數百字節。
維護繁瑣
如果是通過 Web 服務開啓的，那麼每次調整策略，都得修改配置甚至重啓服務，很是麻煩。
兼容性不高
目前只有高版本的瀏覽器支持，而 IE 系列的則幾乎都沒能很好的支持。
如果某些攻擊只爭對低版本的瀏覽器，那麼很有可能出現大量遺漏。
模擬的 CSP
原理
事實上在 CSP 出現的好幾年前，就有一個能夠監控跨站資源的方案，下面就來分享下。
寫過 JS 的都知道，如果需要給大量元素監聽事件，無需對每個元素上都進行綁定，只要監聽它們的容器即可。當具體的事件冒泡到容器上，通過 event.target 即可獲知是哪個元素產生的。
腳本、圖片、框架等元素加載完成時，都會產生 onload 事件；而所有元素都位於『文檔』這個頂級容器。因此我們監聽 document 的 onload 事件，即可獲知所有加載資源的元素。
不過 onload 這個事件比較特殊，無法通過冒泡的方式來監聽。但在 DOM-3 標準模型裏，事件還有一個『捕獲』的概念，這也是爲什麼 addEventListener 有第三個參數的原因。
我們通過事件捕獲機制，將其拿下，從而監控文檔級別的全局 onload 事件。
<script>
document.addEventListener('load', function(e) {
console.log(e.target);
}, true);
</script>
<script src="https://libs.baidu.com/jquery/1.9.0/jquery.js"></script>
<iframe src="https://www.baidu.com/"></iframe>
類似的，如果資源加載失敗，會觸發 onerror 事件。我們也可同時將其捕獲，跟蹤那些暫時不可用的跨站資源。
優勢
通過腳本的方式，就可以更靈活的處理問題了。規則的黑白名單，上報方式、格式等等，都可以自己來定義。最重要的是，我們能夠獲得詳細的違規 URL 了！
相比後端配置，前端腳本更新維護起來容易的多。而且得益於瀏覽器緩存，無需每次更新配置，節省很多資源。
增強
也許你已經發現了，這隻能實現 CSP 的 Report-Only 功能，根本無法進行攔截。而且其他的內聯事件、網絡通信等也沒有涉及。
不過本文的主題已經說了，只是監控跨站資源而已，並不攔截。事實上，如果能夠做到及時發現問題，就很不錯了。
如果非得通過 JS 來實現攔截功能，可以參考之前的『XSS 前端防火牆系列』：
雖然可以更嚴格的防護，但實現起來更臃腫，性能開銷也更大。要是攔截了正常的業務功能，造成的損失會更大。
而使用如今這個小技巧，只需幾行代碼即可實現，性能消耗忽略不計。
缺陷
當然，那麼簡單的方案肯定無法全面。
由於我們只監聽文檔容器，有些還未加入到文檔的元素產生的事件，我們就無法捕獲到了。最典型的就是：
new Image().src = '...'
雖然創建的 HTMLImageElement 對象具有 onload 事件，但是此時還只是一個離屏元素，事件就無法對外傳播了。
如果非得解決，只能通過函數鉤子的方式監控 URL。
此外，IE9 以下的瀏覽器不支持 DOM-3，而 attachEvent 是無法設置捕獲的，因此我們還需一個後備方案。畢竟國內低版本 IE 用戶仍有不少，即使能實現部分功能，也勝於無。
後備
事實上，即使主流瀏覽器，有些特殊元素並沒有 onload 事件，例如 Flash 插件。
爲了彌補這些不足，同時儘可能保持簡單高效，我們使用定時輪詢的方式，對特定元素進行掃描。這裏使用一個大家都知道，但未必都清楚的方法：document.getElementsByTagName。
這個功能都知道，但返回的類型或許很少琢磨。他返回的並不是一個 Array，也不是 NodeList，而是 HTMLCollection。
在 W3C 規範描述中，有一個顯眼的詞 『live』，已經道出了這個接口的獨特之處——它是一個動態的集合，能隨着容器內元素的增減而變化。
因此，我們事先映射出文檔容器內的元素，之後即可隨時查詢集合了。
<button id="btn">Load Script</button>
<div id="stat"></div>
<script>
function log(str) {
var line = document.createElement('div');
line.innerHTML = str;
stat.appendChild(line);
}
// 這是個動態集合，只需查詢一次即可！
var colScript = document.getElementsByTagName('script');
setInterval(function() {
var display = [];
// 可以訪問到最新的記錄
for (var i = colScript.length - 1; i >= 0; i--) {
var el = colScript[i];
if (el.src) {
// check url
display.push(el.src);
}
}
log('num: ' + display.length + ' list:' + display.join(',') );
}, 1000);
// [test] load script
btn.onclick = function() {
var el = document.createElement('script');
el.src = 'http://libs.baidu.com/jquery/1.9.0/jquery.js';
document.body.appendChild(el);
}
</script>
除了 SCRIPT，我們還可以監控其他存在隱患的元素，例如：EMBED，OBJECT，IFRAME 等等。這樣即使是低版本的 IE 用戶，也能參與預警上報了，比起完全沒有好的多。
當然，這種簡單方法也很容易被繞過。如果腳本刪除了自身元素，那麼我們就無法跟蹤到了。而腳本一旦運行就已在內存裏，即使元素節點被移除，仍然能繼續運行。
不過，對於一般的情況也足夠應對了。通常運行商的廣告劫持，大多都很落後。即使要進行後期對抗，也可以利用之前的前端防火牆，使用嚴格的方案。
擴展信息
見過 CSP 日誌的大多都會很困惑，出現的這些違規資源，究竟位於頁面何處。由於沒有確切的細節，給排查工作帶來很大困難。
畢竟，絕大多數的上報問題，都是無法復現的。它們要麼是運行商的廣告，或者是瀏覽器插件。難很通過這些日誌，來定位問題所在。
既然如今使用自己的腳本來實現，理應帶上一些有意義的信息。除了資源類型和詳細 URL，我們還需要一個能夠定位問題所在的參數——DOM 路徑。
將每層元素的 #id 和 .class 跟隨標籤名，得到一個標準的 CSS 選擇器。通過它，即可非常容易的定位到違規元素，同時也能用於統計和分析。
例如出現頂級元素就是 SCRIPT 的，顯然這是一個被插入到 <html> 之外的腳本，很有可能就是運營商注入的廣告腳本。
例如出現 HTML > BODY > ... > DIV.editor-post > SCRIPT 這樣帖子容器裏的腳本，那麼極有可能是出現 XSS 了。正常情況下，用戶內容區域並不會出現腳本元素。
通過詳細的上報日誌不斷學習，後端即可越來越精準的分析出問題所在。
而這些，目前的 CSP 難以實現。
上報方式
吸取 CSP 報告的不足之處，我們使用更靈活的方式。
對於運營商廣告那樣的跨站資源，反覆上報同樣的信息，是毫無意義的，只會浪費帶寬資源。對於同一類警告，一定時間內上報一次就後夠了。
利用 URL、DOM 路徑等信息，可以更容易的將日誌進行客戶端去重。通過本地存儲的記錄，就不必每次都上報了，在本地記錄違規的次數即可。
對於不嚴重的警告，本地也可以累計到一定的數量再上報。這樣多條日誌一次發送，即可大幅減輕後端壓力。甚至還可以考慮壓縮內容，節省網絡帶寬。
只有讓前端進行負載維護，纔不至於大規模部署的場合下，接收端被海量的誤報日誌拖垮。
總結
儘管 CSP 的初衷很美好，但到如今，仍只是能用，並沒有做到好用。因此，實際面臨的問題，還是得靠自己來解決。
當然，標準的制定本來就是受益於大衆的，我們也希望 CSP 標準能發展的越來越好用。