W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2015

Re: CORS performance

From: Bjoern Hoehrmann <derhoermi@gmx.net>
Date: Tue, 17 Feb 2015 20:18:46 +0100
To: Anne van Kesteren <annevk@annevk.nl>
Cc: WebAppSec WG <public-webappsec@w3.org>, WebApps WG <public-webapps@w3.org>, Monsur Hossain <monsur@gmail.com>, Jonas Sicking <jonas@sicking.cc>, Dale Harvey <dale@arandomurl.com>
Message-ID: <be47eahapmjldvqv3dtv8qs0ggrtfuso4m@hive.bjoern.hoehrmann.de>
* Anne van Kesteren wrote:
>With the recent introduction of CSP pinning, I was wondering whether
>something like "CORS pinning" would be feasible. A way for a server to
>declare that it speaks CORS across an entire origin.
>The CORS preflight in effect is a rather complicated way for the
>server to announce that it can handle CORS. We made it rather tricky
>to avoid footgun scenarios, but I'm wondering whether that is still
>the right tradeoff.
>Something like:
>  CORS: max-age=31415926; allow-origin=*; allow-credentials=true;
>allow-headers=*; allow-methods=*; expose-headers=*

Individual resources should not be able to declare policy for the whole
server, HTTP/1.1 rather has `OPTIONS *` for that, which would require a
new kind of "pre-flight" request. And if the whole server is fine with
cross-origin requests, I am not sure there is much of a point trying to
lock it down by restricting request headers or methods. I suppose some-
thing like this could be implemented, but I don't think "CORS pinning"
is quite the right analogy.
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
D-10243 Berlin · PGP Pub. KeyID: 0xA4357E78 · http://www.bjoernsworld.de
 Available for hire in Berlin (early 2015)  · http://www.websitedev.de/ 
Received on Tuesday, 17 February 2015 19:19:30 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:14:43 UTC