Re: CORS performance proposal

On Thu, Feb 19, 2015 at 5:29 AM, Anne van Kesteren <annevk@annevk.nl> wrote:
> When the user agent is about to make its first preflight to an origin
> (timeout up to the user agent), it first makes a preflight that looks
> like:
>
>   OPTIONS *
>   Access-Control-Request-Origin-Wide-Cache: [origin]
>   Access-Control-Request-Method: *
>   Access-Control-Request-Headers: *

This would make CORS preflight even slower for every server that
doesn't implement the new proposal (i.e. every currently-deployed
server and probably most servers deployed in the future). Perhaps the
"OPTIONS *" request could be made in parallel with the initial
preflight requests.

But, then, what happens when the information in the "OPTIONS *"
response conflicts with the information in the normal preflight
request?

> I think this has a reasonable tradeoff between security and opening up
> all the power of the HTTP APIs on the server without the performance
> hit. It still makes the developer very conscious about the various
> features involved.

I think developer consciousness is exactly the issue here:

1. Let's say you want to add "OPTIONS *" preflight support to an
existing web application. How do you go about finding all the things
that need to change to make that safe to do? It seems very difficult
to successfully find every place the app assumes it is protected by
the fact that it doesn't do CORS.

2. Similar to #1, let's say that two teams develop two parts of a
website. One of the teams follows normal CORS rules and the other
depends on the proposed "OPTIONS *" mechanism. This would be a
disaster if/when both apps are deployed on the same origin.

3. Because of these issues, an organization forces its developers to
develop every app as though every resource is CORS-enabled, to
future-proof against the scenerio where "OPTIONS *" is deployed in the
future. This makes the development of the web app more difficult and
slower.

4. In the discussion of Entry Point Regulation (EPR) on WebAppSec, the
main argument in favor of it is that it is impossible for developers
to do things like #3 correctly and it is unreasonable for us to expect
them to. I'm don't buy the EPR argument completely, but I do see some
merit in the underlying "secure by default" argument behind EPR.

Because of these concerns, I think that it would be worthwhile to
study a concrete example of the problem, to make sure we correctly
understand the use case we're trying to solve. As we saw yesterday
with the PouchDB/CouchDB example, it is easy to accidentally and
unnecessarily force a preflight. It may also be the case that we can
find other, safer, ways to avoid preflights and/or optimize how they
are done, such as by optimizing CORS for use with HTTP/2 server push
mechanisms. But, we need to see real instances of the problem first.

Cheers,
Brian

Received on Thursday, 19 February 2015 22:20:28 UTC