Be sure to test the 08 html document using the http:// protocol.
01-05 were requests made to api.github.com using curl. I wanted to see what the response headers looked like, where:
- 01 - Simple GET with no credentials.
- 02 - Simple GET with Basic (username:password).
- 03 - Simple GET with Basic, my own user - the response certainly included private information about me, the authenticated user.
- 04 - Creating an OAUTH token - do these, too, have Access-Control-* headers? Yes!
- 05 - Simple GET with Authorization token.
06-09 demonstrate a CORS request from an HTML document on my hard drive (08), loaded by Chrome (28.0.1500.71), where:
- 06 - A GET request to github.com, to discover whether there were any Access-Control-* response headers. Nope, none.
- 07 - A GET request to api.github.com. This one includes the Access-Control-* response headers. Notice that some of the cookies went with this request.
- 08 - The file I opened in Chrome to make the XHR CORS request.
- 09 - An XHR GET request. Be sure to load the HTML document through a server so that you are using the http:// protocol, otherwise the Origin header will be 'null' when loaded in the browser from a file:// URL. The Access-Control-* response headers are there, however, be sure to notice that the request did NOT include any cookies. This is because I did not invoke
.withCredentials = true
on the XHR request.
Allowing all API endpoints to respond with Access-Control-Allow-Origin: *
is not a problem, as long as no one actually attempts to use .withCredentials = true
when they make their call. In that case, the response must also include Access-Control-Allow-Credentials: true
and Access-Control-Allow-Origin
cannot be *
, but should instead be a single value matching the requesting host. The browser will consider the request a failure.
It is interesting to note that responses from api.github.com have this header combination:
Access-Control-Allow-Credentials: true
Access-Control-Allow-Origin: *
Reading the spec here, you'll find this Note in the discussion about supports credentials:
The string "*" cannot be used (as the value of the Access-Control-Allow-Origin header) for a resource that supports credentials.
My concern is further expressed in the discussion about Security Concerns. Namely, if a resource supports credentials, it should also reflect the requesting Origin
as the Access-Control-Allow-Origin
.
When Chrome makes a .withCredentials
XHR request, it will fail the response if it has Access-Control-Allow-Origin: *
, delaring the requirement that the request Origin
must be the value.
When .withCredentials = true
, the cookies which go with the CORS request should be well defined. In working to understand whether HttpOnly session cookies will go, I found that they do indeed. This means that HttpOnly really is about accessing the values from JavaScript, not about preventing it from being sent to it's owning domain when using XHR requests.