- From: Anne van Kesteren <annevk@annevk.nl>
- Date: Fri, 18 Mar 2016 12:57:00 +0100
- 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): https://github.com/whatwg/fetch/issues/251. > 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. -- https://annevankesteren.nl/
Received on Friday, 18 March 2016 11:57:24 UTC