Re: CORS performance proposal

On Thu, Mar 17, 2016 at 8:26 PM, Hewitt, Rory <> wrote:
> Access-Control-Allow-Headers:*

This is now tracked here (thanks for filing):

> The same goes for the Access-Control-Allow-Methods: * response header - it's simply telling the client what it will support, but it COULD be lying. It could still throw an error, no? Not very nice, perhaps, to tell a client that you will support something, and then not support it, but not a security problem, surely.

The CORS preflight is effectively a check whether the URL supports
CORS and has enough knowledge about CORS to competently respond to
future CORS requests to that URL. That is why that dance exists.

As Craig points out, the problem is that when we loosen the
requirements, that is, make the dance less complicated, copy-and-paste
might happen and security issues could become more commonplace.


Received on Friday, 18 March 2016 11:57:24 UTC