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

Re: Removing the same(ish) origin restriction on report-uri

From: Adam Barth <w3c@adambarth.com>
Date: Mon, 27 Feb 2012 23:09:01 -0800
Message-ID: <CAJE5ia9x=Qe_Quv-3buO3cYxytV_c1G4Dc1eK-eMJoCWV3yh-w@mail.gmail.com>
To: "Ware, Ryan R" <ryan.r.ware@intel.com>
Cc: public-webappsec@w3.org
On Mon, Feb 27, 2012 at 7:27 PM, Ware, Ryan R <ryan.r.ware@intel.com> wrote:
> On Tue, Feb 28, 2012 at 10:01 AM, Adam Barth <w3c@adambarth.com> wrote:
>> I went through all the feedback on CSP violation reports today and
>> made a bunch of edits based on our previous discussions.  I wanted to
>> re-confirm one of those edits with the list:
>> http://dvcs.w3.org/hg/content-security-policy/rev/275074d083aa
>> In that edit, I've removed the restriction that the report-uri needs
>> to have the same scheme, port, and registry-controlled domain as the
>> document-uri.  Originally, we had this restriction because the
>> violation reports contained sensitive information, such as
>> request-headers.  Since then, we've changed the form of the violation
>> reports a bit so that there isn't nearly as much sensitive information
>> in the reports (which means we can remove the "ugly" dependency on the
>> public suffix list).
> Can we get an explicit list of which portions of the reports might still
> contain sensitive information to better judge if the change is appropriate?

-> The address of the protected document, with any <fragment> component removed

-> The referrer attribute of the protected document

-> URI of the resource that was prevented from loading due to the
policy violation, with any <fragment> component removed

-> The policy directive that was violated

-> The original policy as received by the user-agent.

None of these contain particularly sensitive information, as far as I can tell.


>> This edit seems consistent with our April 2011 discussions on this
>> topic, but since that was a while ago, I wanted to re-confirm with the
>> list.
>> Thanks!
>> Adam
Received on Tuesday, 28 February 2012 07:10:06 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:26 UTC