Enabling CORS

Get richer error data by asking browsers to trust your scripts.

Are you hosting your code on a CDN, or on a different domain than your site's? You will need to enable CORS support to get rich error data.

The suggestions here are not Errorception-specific, and are based on emerging web standards. Following these guidelines generally improves your debugging experience, and helps Errorception gather richer error data.

Due to a potential security issue, browsers traditionally don't provide access to error data if the script violates the same-origin policy. Instead, browsers just report a meaningless Script error on line 0, with no additional data.

However, since you can trust your own scripts, you can ask browsers to enable CORS for your scripts. Enabling CORS lets you bypass the same-origin policy in a secure way, much like how cross-domain ajax requests work. This lets you gather errors from the widest range of browsers.

It's really easy to do too. You will only need to make two little changes to your existing setup.

  1. Send the CORS headers for your script files

    Tweak your CDN's configuration to send an extra HTTP header with the response for your script files. The header should look as follows:

    Access-Control-Allow-Origin: *

    Using CloudFront? Learn more about configuring CORS on CloudFront.

  2. Modify your script tags

    Script tags have a new (yet non-standard) attribute called crossorigin, which allows errors to be made available to window.onerror. Read more about the crossorigin attribute.

    The most conservative value for this attribute is anonymous. As an example, if you were to load script.js from the CDN, you'd have to modify your markup to look as follows:

    <script src="https://cdn.example.com/script.js" crossorigin="anonymous"></script>

Note: You must specify both the HTTP header and the crossorigin attribute for this to work correctly. Specifying only one or the other will cause the browser to not evaluate your code.

Browser support

Internet Explorer doesn't recognise the crossorigin attribute, but it doesn't block cross-origin errors from window.onerror either. So, even if you don't do any of this, all errors from IE will still be recorded. This is true across all versions of IE, from the oldest to the very latest.

All of the rest of the popular browsers do not report errors to window.onerror from cross-origin scripts without these changes. Instead, they report a meaningless Script error with no additional data, which Errorception doesn't record. If you do specify the header and the attribute, Chrome and Firefox make error data available for cross-origin scripts. More browsers are expected to follow suit soon. Standardisation for this new attribute has been proposed.