W3C home > Mailing lists > Public > public-webappsec@w3.org > February 2015

Re: CORS performance

From: Devdatta Akhawe <dev.akhawe@gmail.com>
Date: Tue, 17 Feb 2015 11:32:45 -0800
Message-ID: <CAPfop_0V+YuNQCeQ+ZmXqqLcyjvv=UFVG-Q-66HO+28KMxLfhg@mail.gmail.com>
To: Anne van Kesteren <annevk@annevk.nl>
Cc: Bjoern Hoehrmann <derhoermi@gmx.net>, 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>
+1 to Anne's suggestion. The current design is pretty terrible for API
performance. I think a request to / with OPTIONS or something, with a
response that requires some server side logic (like return the random
number UA just sent) is pretty darn secure.


On 17 February 2015 at 11:24, Anne van Kesteren <annevk@annevk.nl> wrote:
> On Tue, Feb 17, 2015 at 8:18 PM, Bjoern Hoehrmann <derhoermi@gmx.net> wrote:
>> Individual resources should not be able to declare policy for the whole
>> server, ...
> With HSTS we gave up on that.
>> HTTP/1.1 rather has `OPTIONS *` for that, which would require a
>> new kind of "preflight" 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.
> Yeah, I wasn't sure whether those should all be listed. Maybe simply
> declaring you're fluent in CORS in a unique way is sufficient.
> --
> https://annevankesteren.nl/
Received on Tuesday, 17 February 2015 19:33:32 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:46 UTC