RE: CORS performance proposal

Hey Anne (and Craig),

The thing is, there will always be a tradeoff between security and usability. If we go the approach of requiring strict security, then we are at risk of it becoming too complex, and users won't use it at all.

FWIW, my experience 'in the trenches' with developers who have implemented (or tried to implement) CORS, is that they almost always got it wrong, at least initially. These were good, smart, technical programmers, who worked for non-tech companies, and who didn't understand the CORS spec, and therefore just muddled their way through.

The original intent of CORS was, I assume, that developers would spend time figuring out exactly which headers the application should allow, and only allow those to be processed by the application. However, that is (again, in my experience) rarely the case - developers simply list all the headers that they can possibly think might be sent by an API and allow them. Or they go the route of mirroring back the AC-Request-Headers value. Partly this may be due to the fact that the team adding the XMLHttpRequest call in the client-side code may not be the same team that wrote the backend API in the first place - it's the former team the defines what headers will be sent, and it's the latter team that defines what value should be returned  in AC-Allow-Headers.

In either case, however, the risk, while there, is low. Perhaps if a server returns a value of AC-Allow-Headers: *, a malicious hacker can send unexpected headers to the application, but that's not to say that the application must process them - after all, the AC-Allow-Headers header is simply there to stop the browser from sending the request in the first place, but that can easily be bypassed by using a non-compliant user agent (e.g. cURL).

Thanks,

Rory

-----Original Message-----
From: Anne van Kesteren [mailto:annevk@annevk.nl] 
Sent: Friday, March 18, 2016 4:57 AM
To: Hewitt, Rory <rhewitt@akamai.com>
Cc: public-webappsec@w3.org
Subject: Re: CORS performance proposal

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 17:06:42 UTC