Why the restriction on unauthenticated GET in CORS?

As I understand, a browser receiving even an unauthenticated GET request on a resource from a JavaScript Agent,  will pass the result on to the JS Agent only if the server adds the 

   Access-Control-Allow-Origin: http://hello-world.example

header to the response. 

I could not quite find it specified clearly in the spec that this has to be so, but it seems to flow from the example given in the introduction.

[[
If a resource author has a simple text resource residing at http://example.com/hello which contains the string "Hello World!" and would like http://hello-world.example to be able to access it, the response combined with a header introduced by this specification could look as follows:

Access-Control-Allow-Origin: http://hello-world.example

Hello World!
]]

And it is the experience of this being required that led me to build a CORS proxy [1] - (I am not the first to write one, I add quickly)

So my argument is that this restriction could be lifted since 

 1. GET is indempotent - and should not affect the resource fetched
 2. If there is no authentication, then the JS Agent could make the request via a CORS praxy of its choosing, and so get the content of the resource anyhow.
 3. One could still pass the Origin: header as a warning to sites who may be tracking people in unusual ways.

  Lifting this restriction would make a lot of public data available on the web for use by JS agents cleanly. Where requests require authentication or are non-indempotent CORS makes a lot of sense, and those are areas where data publishes would need to be aware of CORS anyway, and should implement it as part of a security review. But for people publishing open data, CORS should not be something they need to consider.

Henry


[1] https://github.com/read-write-web/rww-play/blob/master/app/org/w3/readwriteweb/play/CORSProxy.scala

Social Web Architect
http://bblfish.net/

Received on Wednesday, 18 July 2012 03:42:10 UTC