- From: Emily Stark <estark@google.com>
- Date: Fri, 9 Jun 2017 08:10:43 -0700
- To: Martin Thomson <martin.thomson@gmail.com>
- Cc: Patrick McManus <mcmanus@ducksong.com>, httpbis <ietf-http-wg@w3.org>, Anne van Kesteren <annevk@annevk.nl>
- Message-ID: <CAPP_2SY8h-ymtTubY0GMLqWctP4MXXu9nSiUU228gJ5drzZZQg@mail.gmail.com>
On Fri, Jun 9, 2017 at 8:01 AM, Martin Thomson <martin.thomson@gmail.com> wrote: > On 9 June 2017 at 16:53, Emily Stark <estark@google.com> wrote: > > CSP reporting isn't added to the CORS whitelist. It's been in violation > of > > CORS for years and there are some vague plans to fix it by sending > > preflights, but adding it to the whitelist hasn't really been discussed. > > Anne has said that he prefers not to add more to the whitelist, which I > > think is a reasonable stance. (see > > https://lists.w3.org/Archives/Public/public-webappsec/2017Feb/0009.html > -- > > though to be fair, the same text/plain idea is rejected in that thread as > > well) > > > > In addition to the fact that there's not really any principled reason for > > expanding the whitelist, it would mean that, say, an XHR can send the new > > header value, which shouldn't really be allowed. > > Ahh, I remembered that discussion, but failed to get that critical > detail. My point is that if you want to avoid a preflight, then make > sure that you have an analysis to back it up, don't just dodge the > issue by using a whitelisted MIME type. > > If that means using a preflight, then great. If we go back to first > principles, the "POST to intranet site" case would seem to suggest > that some preflighting is warranted. > > Ultimately, I want the same answer for this and for CSP reports. I > would rather not add this to the pile of violating mechanisms though. > These are quite different scenarios though. With CSP, sending preflights is totally doable and makes sense, except for the fact of the widely deployed reporting servers that would break if we suddenly started requiring them to respond to preflights. Expect-CT and HPKP are done as part of certificate verification and it's not clear that they should be governed by CORS any more than OCSP requests or any request made by the OS in the course of loading a webpage. I agree with your "first principles" argument that if they are cross-origin requests triggered in the course of loading a web page, then they can be used by malicious web content and should be subject to CORS... but at the same time I'm not sure that it's practical to require that any request at any layer of the system triggered during the course of loading a web page should go through Fetch and send preflights if needed.
Received on Friday, 9 June 2017 15:11:38 UTC