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-Origincrossorigin加不了外部注入代码，如浏览器插件、定制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 ErrorTwitter: 通过 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，对于通用的系统性问题，应该找到系统性解决方案，进而治标治本。​

关键词： 错误信息 如何处理 解决方案 实际影响 远远不够