832587 - Scripts do not get evaluated if the script tag uses the crossorigin attribute and the server doesn't send a access-control header

Status: RESOLVED INVALID

(Core :: Security, defect)

Description

[Rakesh Pai]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_2) AppleWebKit/537.17 (KHTML, like Gecko) Chrome/24.0.1312.52 Safari/537.17

Steps to reproduce:

Code here: https://gist.github.com/4571053

The HTML page references an external script tag with a cross-origin attribute. The external script sets a global variable. The markup also has another inline script to alert the value of the global variable. The expectation is that the inline alert will reflect the value of the global variable set in the external script.


Actual results:

Behavior depends on whether the external script was sent with "Access-Control-Allow-Origin" header or not. If the header is not set, the inline script throws a ReferenceError. This seems to indicate that the script wasn't loaded. This can be verified by using Firebug later to check if there's a "foo" variable in global scope, and there isn't. (The script does get downloaded, as can be verified from the "Net" tab in Firebug.)

However, the script loads perfectly fine when the access control header is set.

Behaviour verified in Firefox 17 and 18.


Expected results:

Ideally, the presence or absence of the access-control header shouldn't affect script evaluation. I'm not sure if this behaviour in Firefox is intentional.

I've verified that Google Chrome behaves as one would expect, where the presence (or absence) of the header doesn't affect script evaluation.

AFAICT, this isn't a problem for production websites, but it makes dev workflows harder since now developers should either not use crossorigin attributes at dev time, or should use crossorigin attributes and ensure that the server sends the access-control header to go with it.

Comment 1

[Boris Zbarsky [:bzbarsky]]

The behavior is intentional, and quite clearly required by the CORS spec.  A CORS load that doesn't see the right headers is treated as a network error for the resource.

If Chrome isn't doing that, please do file a bug on them.  I do know their CORS implementation gets this wrong in many other cases.

Comment 2

[Boris Zbarsky [:bzbarsky]]

I filed https://bugs.webkit.org/show_bug.cgi?id=107389 so no need to do that.