Description
When a script that isn't served from the same origin as the document throws an error, then the error message exposed to window.onerror is "Script error." and the stack trace is empty.
This is to spec and it can be worked around in some browsers by
- serving the script with CORS headers
- requesting the script as CORS.
While the behavior is understandable, it leads to bad developer experience in practice and is overzealous with respect to the threat model.
My understanding of the threat model is that it is worried about attackers circumventing CORS restrictions by e.g. script src-ing a privileged file from a cross origin and then gaining insights from the error message that happens because the file is not valid JavaScript.
I think browsers could successfully prevent the threat while maintaining most of the developer experience:
- The "Script error." rewriting should be limited to initial execution of a script, because all other stack entry points can be wrapped in try-catch and hence aren't subject to the limitation anyway.
- Potentially the rewriting of the error message could be limited to SyntaxError only.
Since SyntaxErrors are essentially irrelevant in JavaScript production monitoring, these changes would reinstate the ideal developer experience while maintaining the desired protection against data leaks.
As an additional data point: Safari& Chrome seem to follow the spec but Edge & IE do not handle cross origin errors specifically at all and provide full exception info.