- From: Jonas Sicking <jonas@sicking.cc>
- Date: Mon, 23 Feb 2015 10:55:18 -0800
- To: Henri Sivonen <hsivonen@hsivonen.fi>
- Cc: Brad Hill <hillbrad@gmail.com>, Anne van Kesteren <annevk@annevk.nl>, WebAppSec WG <public-webappsec@w3.org>, WebApps WG <public-webapps@w3.org>, Monsur Hossain <monsur@gmail.com>, Dale Harvey <dale@arandomurl.com>
On Mon, Feb 23, 2015 at 7:15 AM, Henri Sivonen <hsivonen@hsivonen.fi> wrote: > On Tue, Feb 17, 2015 at 9:31 PM, Brad Hill <hillbrad@gmail.com> wrote: >> I think it is at least worth discussing the relative merits of using a >> resource published under /.well-known for such use cases, vs. sending >> "pinned" headers with every single resource. > > FWIW, when CORS was designed, the Flash crossdomain.xml design (which > uses a well-known URL though not under /.well-known) already existed > and CORS deliberately opted for a different design. > > It's been a while, so I don't recall what the reasons against adopting > crossdomain.xml or something very similar to it were, but considering > that the crossdomain.xml design was knowingly rejected, it's probably > worthwhile to pay attention to why. A lot websites accidentally enabled cross-origin requests with cookies. Not realizing that that enabled attackers to make requests that had side-effects as well as read personal user data without user permission. In short, it was very easy to misconfigure a server, and people did. This is why I would feel dramatically more comfortable if we only enabled server-wide opt-in for credential-less requests. Those are many orders of magnitude easier to make secure. / Jonas
Received on Monday, 23 February 2015 18:56:16 UTC