W3C home > Mailing lists > Public > public-webappsec@w3.org > March 2016

Re: CORS performance proposal

From: Anne van Kesteren <annevk@annevk.nl>
Date: Fri, 18 Mar 2016 12:57:00 +0100
Message-ID: <CADnb78gmGyj07VqZLFa4zAT9a0spBbq4vdHmidx30=BeE15OYA@mail.gmail.com>
To: "Hewitt, Rory" <rhewitt@akamai.com>
Cc: "public-webappsec@w3.org" <public-webappsec@w3.org>
On Thu, Mar 17, 2016 at 8:26 PM, Hewitt, Rory <rhewitt@akamai.com> 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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:55 UTC