On 02/04/2015 12:10 AM, Mike West wrote: > On Wed, Feb 4, 2015 at 8:42 AM, Eric Mill <eric@konklone.com > <mailto:eric@konklone.com>> wrote: > > This means that CSP would need to be delivered over HTTP, and not > by Let's Encrypt (unless LE had a mode explicitly meant for sites > to triage HTTPS work). > > > This is something that can certainly be done now. That is, sending > `Content-Security-Policy-Report-Only: default-src https:; report-uri > /reporting/endpoint` will flood you with the insecure requests your > site is making, regardless of whether the site itself is delivered > over HTTP/HTTPS. CSP checks happen before mixed content checks for > exactly this use case. FWIW, this is exactly how we detected mixed content at Twitter, and it worked great. I wrote this up on Stack Overflow ages ago, but I've been meaning to write a proper blog post about it: http://stackoverflow.com/questions/4129496/detect-broken-lock-icon-mixed-secure-insecure-content-from-javascript. What we did in practice: The CSP header for mixed content detection was sent only on HTTPS requests and only to 1% of live users, to avoid flooding the endpoint. Also, the same header was set in enforce mode for 100% of employee accounts, so engineers who introduced mixed content would see it right away (this was before mixed content blocking, though it continued to be useful for mixed passive content).
Received on Wednesday, 4 February 2015 19:20:33 UTC