- From: Martin Thomson <martin.thomson@gmail.com>
- Date: Fri, 9 Jun 2017 17:01:26 +0200
- To: Emily Stark <estark@google.com>
- Cc: Patrick McManus <mcmanus@ducksong.com>, httpbis <ietf-http-wg@w3.org>, Anne van Kesteren <annevk@annevk.nl>
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.
Received on Friday, 9 June 2017 15:02:01 UTC