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

Re: CORS performance proposal

From: Hewitt, Rory <rhewitt@akamai.com>
Date: Thu, 17 Mar 2016 19:26:46 +0000
To: "public-webappsec@w3.org" <public-webappsec@w3.org>
Message-ID: <893c50a7dd494870a0cc16b7c124ce34@usma1ex-dag1mb3.msg.corp.akamai.com>
Hey Anne,

I've only just seen this, so I'm late to the game, but I have some input...

>From the point of view of a CDN (such as Akamai, for whom I work), the ability to specify

Access-Control-Allow-Headers:*
Access-Control-Allow-Methods: *

would be useful. Many customers use our proxy to provide the response to the OPTIONS preflight request directly (thereby reducing the load on their origin servers), but without explicit input from them as to exactly which headers their application will allow, we fall back on code which 'mirrors' back the value in the Access-Control-Request-Headers request header - which is effectively what Access-Control-Allow-Headers:* would do. This would reduce the code at our end to do the parsing/mirroring process.

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.

To clarify, if the browser makes a DELETE request (triggering a preflight OPTIONS request), to which my origin responds with (amongst others headers):

Access-Control-Allow-Methods: GET, HEAD, POST, DELETE, OPTIONS

and the browser then relies on this to make the DELETE request, my origin could still respond to the DELETE with a 403 or a 5xx response. Basically, the response to the OPTIONS was a lie - I was never going to allow a DELETE. So where is the security implication?

Note that I'm not speaking for Akamai in any official capacity.

Thanks,

Rory

Senior Solutions Architect
Global Services & Support
Akamai Technologies
Tel: (408) 650-0035
Received on Friday, 18 March 2016 10:25:03 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:18 UTC