Script errors are thrown when an error originates from a JavaScript file, served from a different origin (different domain, port, or protocol), are caught by the global window.onerror handler. Script Error is a symptom of a Same-Origin Policy violation in the browser.
The same-origin policy restricts how a document or script loaded from one origin can interact with a resource from another origin. Same-origin Policy is used as a means to prevent some of the Cross-site Request Forgery attacks.Script error is painful because even though there’s an error occurring, you don’t know what the error is, nor from which code it’s originating. And that’s the whole purpose of window.onerror – getting insight into uncaught errors in your application.
To better understand what’s going on, consider the following example HTML document, served at http://www.acme.com/test:
<!doctype html>
<html>
<head>
<title>www.acme.com/test</title>
</head>
<body>
<script src="http://www.external-domain.com/app.js"></script>
<script>
window.onerror = function (message, url, line, column, error) {
console.log(message, url, line, column, error);
}
foo(); // call function declared in app.js
</script>
</body>>
</html>Here’s the contents of http://www.external-domain.com/app.js. It declares a single function, foo, whose invocation will always throw a ReferenceError.
// www.external-domain.com/app.js
function foo() {
bar(); // ReferenceError: bar is not a function
}When this document is loaded in the browser and JavaScript is executed, the following is output to the console (logged via the window.onerror callback):
"Script error.", "", 0, 0, undefinedThis isn’t a bug – browsers intentionally hide errors originating from script files from different origins for security reasons. It’s to avoid a script unintentionally leaking potentially sensitive information to an onerror callback that it doesn’t control. For this reason, browsers only give window.onerror insight into errors originating from the same domain. All we know is that an error occurred – nothing else!
Solution
We can side-step the Same-Origin Policy using Cross-Origin Resource Sharing (CORS). CORS is most commonly used to address a different violation in the Same-Origin Policy: allowing cross-domain AJAX calls against external API’s. It can also be used to load JavaScript assets exempt from error obfuscation.
In order to get visibility into errors thrown from scripts originating from different origins, you must set two things.
- Cross origin attribute
- CORS HTTP header
1. Set cross origin attribute
From your web application, you can tell the browser to load CORS JavaScript files with the crossoriginattribute:
<script src="http://www.external-domain.com/app.js" crossorigin="anonymous"></script>This tells the browser that the the target file should be fetched “anonymously”. This means that no potentially user-identifying information like cookies or HTTP credentials will be transmitted by the browser to the server when requesting this file.
2. Set CORS HTTP header
CORS is short for “Cross Origin Resource Sharing”, and it’s a set of APIs (mostly HTTP headers) that dictate how files ought to be downloaded and served across origins. Each server, CDN, or vendor that you load JavaScript assets from needs to serve the request with the CORS headers:
Access-Control-Allow-Origin: *By setting the global wildcard, you are indicating that any origin can consume this server. If you want, you can restrict it to only known domains you control, e.g.
Access-Control-Allow-Origin: http://www.acme.com, http://www.external-domain.comOnce both of these steps have been made, any errors triggered by this script will report to window.onerrorjust like any regular same-domain script. So instead of “Script error”, the onerror example from the beginning will yield:
ReferenceError: bar is not defined", "http://www.external-domain.com/app.js", 2, 1, [Object Error]Ready to get Atatus?
Atatus captures better information about JavaScript errors, even in Internet Explorer. It has deeper DOM inspection to capture more error information and the events that led the user to problems. Try out the free 14 day trial – no credit card required. If you have any questions, we’d love to hear from you.
