- From: Hewitt, Rory <rhewitt@akamai.com>
- Date: Thu, 17 Mar 2016 19:26:46 +0000
- To: "public-webappsec@w3.org" <public-webappsec@w3.org>
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