Re: Include page http response code in CSP reports?

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.
>