Browsers may behave in this way as a security feature to protect against potentially malicious scripts injected or hosted by other sites from reading user data such as cookies (quite rightly, I’m sure you’ll agree). This is termed the Same-Origin Policy, and means that scripts only have full access rights if they are loaded from the same origin domain as the original document (when the script passes the CORS validation).
The Same-Origin Policy
The spec and implementation for controlling the Same-Origin Policy is documented nicely here. In particular the Browser Compatibility matrix is a valuable read; you’ll notice proper implementations are only available in recent versions of the evergreen browsers, come with caveats in the bug tickets, or are plain not supported.
There are two key pieces of metadata needed to allow a cross-domain script to report errors correctly in a modern browser. As the documentation lists above, the first is the presence of the ‘crossorigin’ attribute on the appropriate script tag. By example:
<script crossorigin="anonymous" src="http://anotherdomain/foo.js"></script>
The wildcard in this example allows all sites to report errors with full data, and is appropriate for a CDN where the script may be requested by any third-party domain. If this is a private host for a known set of domains, you can provide that list in place of the wildcard.
Different browser behaviours regarding script errors
Depending on what browser your users are running, the above properties may or may not have an effect. This sums up the situation as of writing:
- Chrome 30+
- Firefox 13+
- Opera 12.50+
- Safari (at least 6+)
In these browsers, if the script attribute is present, the HTTP header will need to be also present, otherwise the script will be blocked.
Firefox has additional behavior for RuntimeErrors. These will be provided to
window.onerror regardless of the two properties, as apparantly these aren’t considered a security risk. Syntax errors, however, will be blocked in both Gecko and WebKit browsers, if crossorigin is present but the associated cross-origin domain lacks the header.
- Internet Explorer <= 10
Errors will be reported with all available data in IE 10 and below – now considered a security issue.
- Internet Explorer 11+
Third-party errors will not contain any data, and the attributes are not respected at current time – we’re hoping that Microsoft Edge will resolve this.
Ready to blast away script errors
Like many elements of software dev, there are pitfalls to be aware of when it comes to security and legacy platform support. CORS support and third-party errors are just one of these, but hopefully with the above guide you should be able to ensure you are receiving the error data you need to fix bugs and script errors on your cross-origin scripts, while guarding against malicious third-party scripts and script injection.
Got questions about this post? Let us know in the comments section below. If you haven’t tried out Raygun Crash Reporting, see what the buzz is about by starting your free14-day trial here, no credit card needed, or book a demo with a team member here.