X-Script-Origin, we hardly knew ye

On Thursday, Robert Kieffer filed an interesting bug in both the WebKit and Mozilla bug trackers:

WebKit and Mozilla browsers redact the information passed to window.onerror for exceptions that occur in scripts that originate from external domains. Unfortunately this means that for large institutions (like us here at Facebook) that use CDNs to host static script resources, we are unable to collect useful information about errors that occur in production.

Why do browsers redact this information in the first place?  The answer is actually a combination of two factors:

1. Although browsers generally prevent one origin from reading information from another origin, the script element, like the image element, is a bit of a loophole: an origin is allowed to execute a script from any other origin.  (This exception has wide-ranging implications on both security and commerce on the web.)
2. The script element ignores the MIME type of resources it loads.  That means if a web page tries to load an HTML document or an image with the script element, the browser will happily request the resource and attempt to execute it as a script.

At first blush, these two facts would seem to imply a serious security vulnerability.  Certainly executing a script leaks a great deal of information about the script and ignoring the MIME type means a malicious web site can cause the browser to execute any resource, regardless of the sensitivity of the resource (e.g., an attacker can execute the HTML that represents your email inbox as if it were JavaScript).

Fortunately, we're able to snatch security from the jaws of vulnerability because of a happy coincidence: resources that contain sensitive information happen to fail to parse as valid JavaScript (at least usually).  For example, your email inbox probably consists of HTML that quickly throws a SyntaxError exception when executed as JavaScript.  (The consequences of expanding JavaScript to include HTML-like syntax is an exercise for the reader.)

Returning to our original question, we now understand that (in an attack scenario) sensitive information actually flows though the JavaScript virtual machine, where it generates an exception.  That exception is then processed by window.onerror!  If browsers did not redact the information they give to window.onerror, they would potentially leak sensitive information to malicious web sites.

How, then, can we address Robert's use case?  Certainly we would like web sites like Facebook to be able to diagnose errors in their scripts.  Robert suggests an "X-Script-Origin" HTTP header attached to the script that would indicate which origins are authorized to see exceptions generated by the script.  Although that would work, that solution seems overly specific to the problem at hand.

A more general solution is for the server hosting the script to inform the browser which origins are authorized to learn sensitive information contained in the script.  (Typically servers would authorize every origin because scripts are usually the same for every user).  We already have a general mechanism for servers to make such assertions: Cross-Origin Resource Sharing.  We can address Robert's use case by adding a crossorigin attribute to the script element that functions similarly to the crossorigin attribute on the image element.  Once the embedding origin is authorized to read the contents of the script, there's no longer any need to redact the exceptions delivered to window.onerror.