W3C home > Mailing lists > Public > public-webappsec@w3.org > March 2013

Re: Include page http response code in CSP reports?

From: Mike West <mkwst@google.com>
Date: Tue, 26 Mar 2013 23:08:25 +0100
Message-ID: <CAKXHy=fsdLJG6GBiYiBumCbM34QHCPHK48CiS15vFXy09Yy9Bw@mail.gmail.com>
To: Neil Matatall <neilm@twitter.com>
Cc: "public-webappsec@w3.org" <public-webappsec@w3.org>
I can't come up with any clever exploits that would be caused by sending
the response code of the protected resource (perhaps as "document-status"
next to "document-uri"?), and there's apparently some marginal value to
adding it. That doesn't mean there aren't any, however...

If no one objects, I'll put together a proposal for that change, but if I'm
missing something, I'd appreciate a heads up. :)

Sending the response code of the blocked resource, on the other hand, would
potentially be problematic, as servers often send different response codes
based on login state, etc. I don't think that's something we could safely
add.

-mike

--
Mike West <mkwst@google.com>, Developer Advocate
Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany
Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91


On Tue, Mar 19, 2013 at 9:16 PM, Neil Matatall <neilm@twitter.com> wrote:

> I'm still not entirely convinced this is worthwhile… just another data
> point to collect
>
> Our 404 page is the same across all applications. The response is
> intercepted and replaced with static content. In this case, the 404 page
> keeps the response headers which causes all kinds of mayhem.
>
> Having the response code of the page may help those aggregating reports
> better understand what is going on. I'm having trouble of thinking of other
> use cases for this feature.
>
>  Our 404 page was not CSP-friendly at all. Being able to see the common
> response code would have helped us narrow it down sooner. For those who
> return 200s for all 2xx, 4xx, and 5xx response codes, this obviously has no
> benefit.
>
> I could see potential privacy issues here, but that is not my area of
> expertise so I'll let others pick that apart.
>
Received on Tuesday, 26 March 2013 22:09:14 UTC

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