I looked at the most recent specification and noted a few things. Apologies if these are repeats of earlier feedback, but they're still outstanding.
1) POST is listed as a "simple method," thereby exempting POST from the "preflight" check. I understand that the rationale for this is that POST already can be automatically generated (by form.submit() APIs), but this does not justify opening a new security hole in the Web; it only makes closing the existing ones more difficult. 2) The following headers are intrinsic to the message and its interpretation, and should be added to the list of simple response headers: - Content-Location - Content-MD5 - Vary - ETag - Date - Content-Range 3) When a server changes the headers in a response based upon the value of the incoming Origin header (as outlined in sections 5.1 and 5.2), it must insert Vary: Origin into *all* responses for that resource; otherwise, downstream caches will incorrectly store it. Be aware that doing so will cause many versions of IE not to cache those responses at all. Another option would be to disallow varying the response based upon the Origin header. 4) Section 5.1, #4: "If the resource wants to expose more than just simple response headers to the API of the CORS API specification..." This is very awkward, and it's not clear what's intended. 5) Using a "preflight" check in combination with a cache exposes sites to DNS rebinding, man-in-the-middle, and potentially other attacks that did not exist before. This should be noted. 6) Requiring a preflight check per-URI is not an efficient use of network resources for applications that use a large number of URIs, as is becoming more prevalent; effectively, it introduces another round-trip for each unsafe request. Handling OPTIONS is also somewhat specialised on many servers. It's also awkward to handle OPTIONS per-URI on many servers. I've raised this several times before, and am still not convinced that the underlying requirement (#8) justifies such a convoluted and ill-concieved design, or indeed is effectively met by this design. Allowing a site to define a 'map' of where cross-origin requests are allowed to go would be more efficient in most cases, would be vastly simpler to implement for servers, and would be similar to many other site-wide policy mechanisms on the Web. Regarding this last issue - I realise that CORS is already shipping and that implementers are unlikely to change. I just didn't want to let this draft go by without commenting, lest someone mistake it for a good design. Regards, -- Mark Nottingham http://www.mnot.net/
