W3C home > Mailing lists > Public > public-webappsec@w3.org > May 2017

Re: Improving CORS security

From: Daniel Veditz <dveditz@mozilla.com>
Date: Wed, 10 May 2017 10:30:57 -0700
Message-ID: <CADYDTCAp3onam6Z47pKs66WtiuNOxbUOg9Lp1TmnDqxtJEP9tQ@mail.gmail.com>
To: James Kettle <james.kettle@portswigger.net>
Cc: "public-webappsec@w3.org" <public-webappsec@w3.org>
On Tue, May 9, 2017 at 8:41 AM, James Kettle <james.kettle@portswigger.net>
wrote:

> - Enabling static trust of multiple origins by supporting a
> space-separated list of origins
>

​I would support syntax for this. Having to programmatically generate the
correct header has always seemed error prone and leads to blind echoing
which is less secure than just using "*".​

- Enabling static trust of all subdomains by supporting the use of partial
> wildcards like https://*.example.com
>

​I have more trepidation here that people will leave themselves too wide
open, but I cautiously support this as a practical necessity given the
first. Would such sites allow credentials, or would they be forced to be
credential-less like '*' ?

Websites accessed over HTTPS can use CORS to grant credentialed access to
> HTTP origins, which partially nullifies their use of HTTPS. Perhaps
> browsers' mixed content protection should block such requests, or at least
> disable allow-credentials for HTTP->HTTPS requests.
>

I disagree. From the document and user point of view it's not at all mixed
content.​ If the HTTPS server doesn't want to give up its data to HTTP
origins it can quite simply not respond with the CORS headers that enable
it. The existing mixed-content blocking behavior leans hard on 3rd-party
services to implement https because as such they can serve anyone, while
with https they cannot serve to https documents.

-
​Dan Veditz​
Received on Wednesday, 10 May 2017 17:31:52 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:23 UTC