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

Re: Reports feature violates the same-origin policy

From: Scott Helme <scotthelme@hotmail.com>
Date: Wed, 15 Feb 2017 22:28:16 +0000
To: "public-webappsec@w3.org" <public-webappsec@w3.org>
Message-ID: <MMXP123MB0718EF6147E6E38F698BD8FDD95B0@MMXP123MB0718.GBRP123.PROD.OUTLOOK.COM>
For CSP 3, would reports sent with a content-type of application/report require a CORS preflight?

Cheers,

Scott.

On 15/02/2017 20:09, Daniel Veditz wrote:
I was being somewhat snarky; I'm not actually proposing we change the reporting content-type. CSP's report-uri uses a Content-Type of application/csp-report. If a hypothetical JSON-consuming server is checking Content-Type they should already be fine. If they aren't then a malicious web site's ability to hit the server with text/plain JSON payloads would pose similar risk. I wouldn't want to generically whitelist application/csp-report if that means arbitrary xhr/fetch could also use those. At least with a real CSP report there are restrictions on the possible data that's sent that are unlikely to match some other service's JSON format.

In CSP 3 report-uri is deprecated in favor of report-to. Report-to uses the reporting service spec which defines a content-type of application/report, and also that the request mode is "cors". Isn't that basically what you want? Can we leave the report-uri behavior alone as a historical artifact of 2011 spec making?

-
​Dan Veditz​


Received on Wednesday, 15 February 2017 22:28:54 UTC

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