Re: CORS performance proposal

Hi Rory,

I'm not in the W3C, but I'd be very uncomfortable with web browsers supporting wildcards, because web developers will just copy/paste these lines for everything.

For an example, look at the old Adobe Flash `crossdomain.xml`, where many websites used:

<?xml version="1.0" ?>
<cross-domain-policy>
  <allow-access-from domain="*" />
</cross-domain-policy>

And they did it to "made things work" (who cares about the security implications).

So, if you choose to parse/reflect (without any white/black lists), that it your choice, but you are hopefully making an informed choice :-)

Whereas most inexperienced developers will hopefully use a simple/hard-coded header, where they specify the headers/methods manually.

Craig





> On 17 Mar 2016, at 19:26, Hewitt, Rory <rhewitt@akamai.com> wrote:
> 
> 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:58:13 UTC