On Mon, Feb 23, 2015 at 11:06 AM, Anne van Kesteren <ann...@annevk.nl> wrote:
> On Mon, Feb 23, 2015 at 7:55 PM, Jonas Sicking <jo...@sicking.cc> wrote:
>> 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.
> Why is that not served by requiring an additional header that
> explicitly opts into that case?

I don't think an extra header is that much harder to deploy than
crosssite.xml is. I.e. I don't see strong reasons to think that people
won't misconfigure.

> That combined with requiring to list
> the explicit origin has worked well for CORS so far.

This could potentially help.

I don't remember the details of how/why people screwed up with
crosssite.xml. But if the problem was that people hosted multiple
services on the same server and only thought of one of them when
writing a policy, then this won't really help very much.

Do we have any data on how common it is for people to use CORS with
credentials? My impression is that it's far less common than CORS
without credentials.

If that's the case then I think we'd get most of the functionality,
with essentially none of the risk, by only allowing server-wide
cookie-less preflights.

But data would help for sure.

/ Jonas

Reply via email to