Do you use an error tracking tool for your website? Have you ever tried to debug a problem that a user reported, and when you looked at your error tracking tool the reported error was simply: “Script Error”? Such errors are impossible to further debug because there is no additional information apart from that message.
In this article, I’ll explain what a script error is, what can cause it and how to fix it, or more precisely, how do we get detailed information for errors that originate in scripts served from a different origin.
Let’s get started!
What Is a Script Error
If you are using an error tracking tool for your frontend code, you might have noticed an error with a rather cryptic “Script error” message. These are errors from your website that originate in JavaScript files served from a different origin (different domain, port, or protocol).
The problem with these errors is that they don’t contain any details, not even the stack trace. This makes it impossible to find the location of the bug in code, which defeats the purpose of using error tracking tools.
What Causes Script Error Messages
Error tracking tools use window.onerror to catch and log uncaught errors.
This works fine most of the time, but when the error is in a JavaScript file served from a different origin the browser will provide only the cryptic Script error. message without any additional information. This is to prevent leaking of potentially sensitive information.
Different origin means that the JavaScript file is hosted on a different domain or subdomain or protocol (http vs https) or port.
The Same-Origin Policy
Browsers enforce the same-origin policy, which means that scripts have full access rights only if they are loaded from the same origin as the website itself.
In an effort to improve loading times most websites will use Content Delivery Networks (CDN) for hosting JavaScript, CSS, and other static content. This means that in most cases, JavaScript files will be served from a different origin than the website itself as the CDN will use a different domain.
If your website has a lot of application code defined in JavaScript files hosted on CDNs and a runtime error happens, the error description that hits the window.onerror event handler won’t have any stack trace or detailed message for you to debug.
How to Fix Script Errors
So how do we fix this, or more precisely, how do we get detailed information for errors that originate in scripts served from a different origin? This is a two step process, we need to make changes both on our website and on the third-party origin.
1. Add `crossorigin` attribute on the script tag
If you are trying to load a script on your website from a different origin and add the script tag like the one below, the browser will refuse to load the script.
`<script src="//third-party.com/index.js"></script>`
To enable cross origin requests for this script you need to add the crossorigin="anonymous" attribute to the tag like this:
`<script crossorigin="anonymous" src="//third-party.com/index.js"></script>`
Now the browser will perform a CORS request for this script but it will omit any sensitive data such as cookies or HTTP authentication data.
2. Return Access-Control-Allow-Origin header on the second origin
Most CDNs will do this by default as their main purpose is serving static files to other origins, but if you are running your own servers for serving static files, they will need to return the following HTTP header for static files:
`Access-Control-Allow-Origin: *`
This will enable browsers to fetch static files from this server from any domain. If you have a known list of domain you want to allow, for example if your website is at www.my-site.com, then you can allow that domain only:
`Access-Control-Allow-Origin: www.my-site.com`
If you are not sure how to add these headers on your servers or the service you are using, you should check out https://enable-cors.org/server.html.
Using a Web Proxy to Remove Script Errors
If you are a developer and you have run into this issue, and you need a quick fix, you could use a web proxy such as CORS Anywhere. The proxy server forwards the requests to the third-party server, and then sends them back to your website with the CORS headers added.
Obviously, you should not use this in a production environment, but it’s a quick solution if you don’t have access to the second origin servers.
Script Errors on Different Browsers
There are some browser quirks that you should be aware of. What we wrote above applies to the latest browser, or more specifically to:
- Chrome 30+
- Firefox 13+
- Opera 12.50+
- Safari (at least 6+)
- Edge 0.10+
Firefox has different behavior for runtime errors. These will be provided to the onerror callback without any obfuscation, even if the script is served from a different origin. Syntax errors will be blocked though if the CORS headers are missing.
Internet Explorer 10 and below will report all available data for errors. This is now considered a security risk. And in Internet Explorer 11+ scripts loaded from different origins will never have any additional data provided, regardless of the CORS headers and the crossorigin attribute mentioned above.
Stopping Script Errors with RUM Solutions
Real user monitoring tools such as Sematext Experience, can help you detect script errors by logging them to a remote server. RUM tools that have error tracking will report such errors as they happen to real users on your website.
When error tracking tools report errors, they usually report a detailed stack trace and error message which helps the developer track down the issue in their code.
But as explained earlier, this special kind of error will be missing this additional information. You can avoid this by following the instructions above to adjust the script tag and the servers from which the script is served.
The Bottom Line
Script Error is a special kind of error that you get when a runtime or syntax error occurs in a script that is served from a different domain, subdomain, or port.
To even detect such errors you need a good monitoring solution. You could go for a real user monitoring solution such as Sematext Experience or a front-end monitoring tool that features RUM, logging, and synthetic monitoring that gives you end-to-end visibility into your application performance, in which case, Sematext Cloud is the tools for you. Use the 14-day free trial to explore Sematext’s features!
If you have already detected such errors with your RUM tools and you are wondering why the stack trace or message is missing, you should follow the instructions above to adjust the script tag or the server from where the files are served.