如何根治Script Error. – 阿里巴巴終端技術- 科技資訊
作者：盧峰（清銳）
本文簡要介紹了Script Error 問題的來龍去脈，但也不局限於Script Error，對於通用的系統性問題，應該找到系統性解決方案，進而治標治本。
Script Error 原因與當前解法
受瀏覽器同源策略限制，未知跨域腳本執行錯誤時，拋出的錯誤信息為”Script error.”，導致開發者無法定位具體錯誤。為了獲取詳細錯誤信息及堆棧，一般解法是給Script 標籤配置crossorigin 屬性，同時對應腳本服務端需配置Access-Control-Allow-Origin 響應頭。
另外還有一些hack 解法，對瀏覽器原生API 做代理，將業務程式碼放在Try Catch 作用域中執行，但寫好代理方法是不容易的，粗製濫造的代理方法會製造很多隱藏Bug，並且大量Try Catch 在一些JS Engine 中也存在額外性能損耗，為了解決Script Error 採用此方案得不償失。
還有什麼問題
- crossorigin 不好加
異步加載腳本套娃，A 加載B，B 加載C，以至於不知道加載了哪些外部腳本
需要服務端配合設置響應頭Access-Control-Allow-Origin
- crossorigin 加不了
外部注入程式碼，如瀏覽器插件、定制Webview 容器（xx 瀏覽器）
- 無效Script Error 數據，難以評估對業務實際影響，並且耗費監控資源
溯源：為什麼是Script Error
從2006 年一篇安全漏洞文章說起：I know if you’re logged-in, anywhere
在那個年代大量網站都是服務端渲染，服務端根據用戶登錄態返回不同頁面內容，黑客通過Script 加載目標站點，用戶已登錄、未登錄返回的Response 內容不同，報錯信息也會有差異，這樣就可以通過報錯信息區分用戶是否登錄，進一步展開針對性的攻擊。
<script src=” http://mail.google.com/mail/”></script>
已登錄：
**未登錄： **
對於其他站點也是類似，錯誤信息中總會有差異，比如亞馬遜登錄和未登錄，報錯的LineNo 不同。
基於此，WHATWG 對錯誤信息透出製定了規範：
Chrome 實現：
《I know if you’re logged-in, anywhere》地址：https://blog.jeremiahgrossman.com/2006/12/i-know-if-youre-logged-in-anywhere.html
Script Error 規範是否能調整
通過以上信息，我們可以理解Script Error 的設計初衷以及其合理性，但我也有疑問，在今天瀏覽器同源策略比較完善的情況下，是否有必要屏蔽所有信息（error message、lineno、colno、url）？能否將發生Script Error 的腳本url 暴露出來，以便開發者收集到錯誤信息時快速定位錯誤來源，這樣也方便評估影響面，比如明顯是注入的腳本錯誤，直接忽略即可。
翻閱WHATWG Github 歷史issue，發現已經有過相關討論，很明確答案是No，大概原因是當前的同源策略已經很全面（複雜），不想在挖坑。以至於對unhanlderejection，連Script Error 都不願意報。
相關討論地址：https://github.com/whatwg/html/issues/2440
unhanlderejection地址：https://github.com/whatwg/html/issues/5051
其他大廠如何處理Script Error
我在幾個大廠網站上做了測試，加載一個第三方腳本，第三方腳本一定會報錯，看看對應站點如何處理。
var s = document.createElement('script');
s.src="https://g.alicdn.com/dinamic/h5-tb-cart/5.0.41/index.min.js";
document.body.appendChild(s);
-
Google：常規處理，直接上報Script Error
-
Twitter: 通過CSP 策略攔截了未知腳本加載，包括Github、FaceBook 都採用類似方案
-
QQ 視頻：除了上報Script Error，並監控上報異步加載的腳本
面向未來我們應該如何處理Script Error
面向未來看問題，我們不能與標準背道而馳，同源策略是當前解決Web 安全問題的重要手段，在未來只會更完善，我們應該積極了解與應用。當前國內互聯網對同源策略的了解與應用大多止步於 Access-Control-Allow-Origin: *，這是遠遠不夠的。
因此，面向未來Script Error 問題Twitter 的處理方式相對合理，只允許站點加載白名單腳本，對白名單腳本逐個做CrossOring 等配置，同時也杜絕了外部腳本注入。對於淘寶來說，受限於業務體量以及歷史包袱，做這種改造難度可想而知，但我們應該朝這個方向努力，而不是讓開發者面對Script Error 手足無措，靠猜測或是加錯誤過濾解決問題。
回到當下，短期的解決方案要增強跨域腳本的感知能力，可以配置CSP Report Only 上報跨域腳本，也可以通過原始手段統計，進而對相關腳本做跨域配置，對於明顯的跨域腳本如埋點、喚端、以及安全系列腳本，缺少crossorigin 的盡快修復。
CSP Report Only地址：https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy-Report-Only
document.querySelectorAll('script[src]:not([crossorigin])')
本文簡要介紹了Script Error 問題的來龍去脈，但也不局限於Script Error，對於通用的系統性問題，應該找到系統性解決方案，進而治標治本。
參考文檔
-
what is script error（地址：https://blog.sentry.io/2016/05/17/what-is-script-error）
-
Cryptic “Script Error.” reported in Javascript in Chrome and Firefox（地址：https://stackoverflow.com/questions/5913978/cryptic-script-error-reported-in-javascript-in-chrome-and-firefox）
-
解決”Script Error” 的另類思路（地址：https://juejin.cn/post/6844903727820718094#heading-6）
-
iOS Privacy: Instagram and Facebook can track anything you do on any website in their in-app browser（地址：https://krausefx.com/blog/ios-privacy-instagram-and-facebook-can-track-anything-you-do-on-any-website-in-their-in-app-browser）
-
I know if you’re logged-in, anywhere（地址：https://blog.jeremiahgrossman.com/2006/12/i-know-if-youre-logged-in-anywhere.html）
-
HTML Spec: Runtime script errors（地址：https://html.spec.whatwg.org/multipage/webappapis.html#runtime-script-errors）
-
“Script error.” message in window.onerror makes bad DevExp trade off（地址：https://github.com/whatwg/html/issues/2440）
-
unhandledrejection should fire even for muted scripts（地址：https://github.com/whatwg/html/issues/5051）
-
Content-Security-Policy-Report-Only（地址：https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy-Report-Only）
