作者：陆风（青蕊）本文简单介绍了ScriptError问题的来龙去脉，但并不局限于ScriptError。对于一般的系统性问题，要找到系统性的解决方案，标本兼治。ScriptError原因及当前解决方法受浏览器同源策略限制。当发生未知跨域脚本执行错误时，抛出的错误信息为“Scripterror.”，导致开发者无法定位具体错误。为了获取详细的错误信息和堆栈，一般的解决方案是为Script标签配置crossorigin属性，同时为相应的脚本服务器配置Access-Control-Allow-Origin响应头。此外，还有一些hack方案，作为浏览器原生API的代理，在TryCatch范围内执行业务代码。但是，编写一个好的代理方法并不容易。粗制滥造的代理方式会造成很多隐藏的bug，大量的TryCatchCatch在一些JSEngine中也会有额外的性能损失，用这种方案来解决ScriptError得不偿失。有什么问题？crossorigin不容易添加异步加载的脚本娃娃，A加载B，B加载C，这样不知道加载了哪些外部脚本，需要服务端配合设置响应头Access-Control-Allow-OriginCrossorigin无法添加外部注入代码，如浏览器插件、自定义Webview容器（xx浏览器）有无效的ScriptError数据，难以评估对业务的实际影响，消耗监控资源Traceability:WhyScriptErrorStartedwitha2006年的安全漏洞文章：我知道你是否登录，任何地方在那个时代，大量的网站都是由服务器渲染的。服务器根据用户的登录状态返回不同的页面内容。黑客通过脚本加载了目标站点。用户登录和未登录时，用户返回的Response内容不同，报错。信息也会有所不同，这样就可以通过错误信息来区分用户是否登录，进而进行有针对性的攻击。Loggedin:Notloggedin:和其他站点类似，错误信息总会有区别，比如Amazonloggedin和未登录，报错的LineNo不一样。基于此，WHATWG制定了错误信息泄露的规范：Chrome实现：《I know if you're logged-in, anywhere》地址：https://blog.jeremiahgrossman...ScriptError规范可以调整吗？通过以上信息，我们可以了解到ScriptError的设计初衷并且是合理的，但我也有疑惑。在浏览器同源策略相对完善的今天，是否需要屏蔽所有信息（错误信息、lineno、colno、url）？能不能把发生ScriptError的脚本url暴露出来，方便开发者在收集错误信息的时候快速定位错误来源，也方便评估影响面。比如明明是注入的脚本错误，忽略即可。翻看WHATWGGithub的历史issue，发现有相关讨论，答案很明确是否定的，可能是因为现在的同源政策已经很全面（复杂）了，不想再挖坑了.以至于对于unhanlderejection，连ScriptError都不愿意报。相关讨论地址：https://github.com/whatwg/htm...unhanlderejection地址：https://github.com/whatwg/htm...其他大厂如何处理ScriptError？我在几大厂商的网站上做了测试，加载第三方脚本，第三方脚本肯定会报错，看看对应站点是怎么处理的。vars=document.createElement('脚本');s.src='https://g.alicdn.com/dinamic/h5-tb-cart/5.0.41/index.min.js';文档.正文。appendChild(s);Google:常规处理，直接报ScriptErrorTwitter:Unknownscriptloading通过CSP策略拦截，包括Github和FaceBook都采用类似的解决方案如何处理ScriptError？展望未来，我们不能违背标准。同源策略是目前解决web安全问题的重要手段，未来只会更加完善。我们应该积极地理解和应用它。目前国内互联网对同源策略的理解和应用大多停留在Access-Control-Allow-Origin:*，远远不够。因此，对于面向未来的ScriptError问题，Twitter的处理方式还是比较合理的。只允许站点加载白名单脚本，并逐一配置白名单脚本，如CrossOring，同时也防止外部脚本注入。对于淘宝来说，受限于业务量和历史包袱，这种转型难度可想而知，但我们应该朝这个方向努力，而不是让开发者面对ScriptError无所适从，靠猜测或者添加错误过滤解决问题。回到现在，短期的解决方案是增强跨域脚本的意识。可以配置CSPReportOnly来报告跨域脚本，也可以使用原有的方式进行统计，然后对相关脚本进行跨域配置。对于埋点、调用端、安全系列脚本等明显的跨域脚本，尽快修复crossorigin的不足。CSPReportOnly地址：https://developer.mozilla.org...document.querySelectorAll('script[src]:not([crossorigin])')本文简单介绍了ScriptError问题的来龙去脉，但是不限于ScriptError，对于一般的系统性问题，应该找到系统性的解决方案，标本兼治。参考文档什么是脚本错误（地址：https://blog.sentry.io/2016/0...）神秘的“脚本错误”。JavascriptinChromeandFirefox报错（地址：https://stackoverflow.com/que...）解决“ScriptError”的另一种思路（地址：https://juejin.cn/post/684490...）iOS隐私：Instagram和Facebook可以在其应用内浏览器中跟踪您在任何网站上所做的任何事情（地址：https://krausefx.com/blog/ios...）我知道您是否在任何地方登录（地址：https://blog.jeremiahgrossman...)HTML规范：运行时脚本错误（地址：https://html.spec.whatwg.org/...）“脚本错误。”window.onerror中的消息使DevExp权衡不利（地址：https://github.com/whatwg/htm..）unhandledrejection即使对于静音脚本也应该触发（地址：https://github.com/whatwg/htm。..)Content-Security-Policy-Report-Only（地址：https://developer.mozilla.org..）
