W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 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.

cheers
dev


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:35 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:27:25 UTC