Repro confirmed in Chrome 56.2888
Firefox 52: not repro-- Report is properly sent.

Repro: https://bayden.com/test/csp/reportmixeduir.aspx

Without UpgradeInsecureRequest, the report IS sent. (See https://bayden.com/test/csp/reportmixed.aspx)

This is especially bad because the UpgradeInsecureRequest specification explicitly suggests pairing UIR with CSP reporting so that web developers can clean up their resource references for legacy browsers that don't support UpgradeInsecureRequest.

Safari 10 and 10.1 match Chrome and do not send the CSP violation report.

I was reminded of this bug when reading the Guardian's HTTPS transition blog post. I think we should fix it, but I'm not sure how.

Right now, we upgrade insecure requests in modifyRequestForCSP(), which gets called before FrameFetchContext::canRequest() which actually checks the CSP and sends reports. [1] So by the time we check CSP and send reports, we've already lost the original pre-upgrade URL.

One idea is to create a report-only version of FrameFetchContext::canRequest() that we call before modifyRequestForCSP(). This roughly lines up with what's suggested by the spec text in [2]. However, I think it would be a little hairy to untangle which parts of canRequest() belong in a report-only version.

Another idea is that modifyRequestForCSP() should store the original, unmodified URL on the ResourceRequest. The original unmodified URL would then get plumbed through to CSPDirectiveList, which would check it and report violations in addition to checking/reporting on the modified URL. I think this would be a bit cleaner to implement, but it doesn't line up as well with the spec text.

Mike, do you have any preference between those two ideas, or any other ideas?

[1] https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/fetch/ResourceFetcher.cpp?sq=package:chromium&rcl=1480422069&l=497

[2] https://w3c.github.io/webappsec-upgrade-insecure-requests/#reporting-upgrades

Just as an FYI— this bug is the primary reason why we have not enabled HTTPS testing on The Verge (or other Vox Media sites). We are really concerned with pages silently breaking without us being able to know where those pages are.

Comment #8: If you pair "Upgrade-Insecure-Requests" with Content-Security-Policy-Report-Only, you'll still get violation reports from browsers that support CSP-RO (e.g. Firefox, Safari, Edge) even as UIR protects your lock icon in Chrome, Firefox and Opera.

Pingity ping ping to mkwst: any thoughts on #7?

Sorry, I missed this earlier.

We certainly should be reporting before upgrading (see steps 3, 4, and 5 of https://fetch.spec.whatwg.org/#main-fetch). It's entirely possible that I wrote the spec for this, and then never implemented it. :/

I think that Emily's suggestion to construct a report-only `canRequest` is pretty reasonable. That's more or less what I thought imagined we were already doing. I'll get it done.

Might be a good bug for elawrence@ if you haven't gotten too far in already, Mike.

Ah, sorry Eric. I didn't realize you wanted to fix this! I would have uploaded a patch on Friday, but writing tests for this reminded me that our handling of redirects is abysmal ( issue 615885 ), so now I'm trying to fix that.

I've uploaded https://codereview.chromium.org/2551893002. Eric, if you'd like to fix this bug, I'm happy for you to either take that as the basis of a patch, or throw it away entirely!

Hey everyone, any update on this bug? I'm hitting the same issue along with some users of report-uri.io :(

Is this still open?

Yes, this is still needed. 

I /think/ the CL in #13 may have stalled because of a parallel CL (https://codereview.chromium.org/2053693002/) which aims to move the CSP U-I-R checking over to the browser process. (That CL also stalled about three months ago.)

I'm working on rebasing/updating Mike's patch for this.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/a98bc6ea35dbcc498eaa7a84b67e91622d8eb4d0

commit a98bc6ea35dbcc498eaa7a84b67e91622d8eb4d0
Author: estark <estark@chromium.org>
Date: Wed Apr 19 20:52:56 2017

Split CSP into pre- and post-upgrade checks

When populating a resource request, before upgrading an insecure request
if appropriate, we now check report-only CSP headers, to ensure that
CSP report-only violations are reported before any modifications of the
request. After modifying the request, we check the enforced CSP headers to
ensure that the request is still allowed.

This is as described in the upgrade-insecure-requests spec:
https://w3c.github.io/webappsec-upgrade-insecure-requests/#reporting-upgrades

Patch stolen from mkwst@

BUG= 625156 
TEST=added web platform test upgrade-insecure-requests-reporting.https.html

Review-Url: https://codereview.chromium.org/2790693002
Cr-Commit-Position: refs/heads/master@{#465741}

[add] https://crrev.com/a98bc6ea35dbcc498eaa7a84b67e91622d8eb4d0/third_party/WebKit/LayoutTests/external/wpt/content-security-policy/frame-src/frame-src-redirect.html
[add] https://crrev.com/a98bc6ea35dbcc498eaa7a84b67e91622d8eb4d0/third_party/WebKit/LayoutTests/external/wpt/content-security-policy/frame-src/frame-src-redirect.html.headers
[add] https://crrev.com/a98bc6ea35dbcc498eaa7a84b67e91622d8eb4d0/third_party/WebKit/LayoutTests/external/wpt/content-security-policy/frame-src/support/frame.html
[add] https://crrev.com/a98bc6ea35dbcc498eaa7a84b67e91622d8eb4d0/third_party/WebKit/LayoutTests/external/wpt/content-security-policy/frame-src/support/testharness-helper.sub.js
[add] https://crrev.com/a98bc6ea35dbcc498eaa7a84b67e91622d8eb4d0/third_party/WebKit/LayoutTests/external/wpt/content-security-policy/securitypolicyviolation/img-src-redirect-upgrade-reporting.https.html
[add] https://crrev.com/a98bc6ea35dbcc498eaa7a84b67e91622d8eb4d0/third_party/WebKit/LayoutTests/external/wpt/content-security-policy/securitypolicyviolation/img-src-redirect-upgrade-reporting.https.html.headers
[add] https://crrev.com/a98bc6ea35dbcc498eaa7a84b67e91622d8eb4d0/third_party/WebKit/LayoutTests/external/wpt/content-security-policy/securitypolicyviolation/support/testharness-helper.sub.js
[add] https://crrev.com/a98bc6ea35dbcc498eaa7a84b67e91622d8eb4d0/third_party/WebKit/LayoutTests/external/wpt/content-security-policy/securitypolicyviolation/upgrade-insecure-requests-reporting.https.html
[add] https://crrev.com/a98bc6ea35dbcc498eaa7a84b67e91622d8eb4d0/third_party/WebKit/LayoutTests/external/wpt/content-security-policy/securitypolicyviolation/upgrade-insecure-requests-reporting.https.html.headers
[modify] https://crrev.com/a98bc6ea35dbcc498eaa7a84b67e91622d8eb4d0/third_party/WebKit/LayoutTests/http/tests/security/contentSecurityPolicy/multiple-report-policies-expected.txt
[modify] https://crrev.com/a98bc6ea35dbcc498eaa7a84b67e91622d8eb4d0/third_party/WebKit/LayoutTests/http/tests/security/contentSecurityPolicy/nonces/import-multiple-blocked.php
[modify] https://crrev.com/a98bc6ea35dbcc498eaa7a84b67e91622d8eb4d0/third_party/WebKit/LayoutTests/http/tests/security/contentSecurityPolicy/nonces/import-reportonly-allowed.php
[modify] https://crrev.com/a98bc6ea35dbcc498eaa7a84b67e91622d8eb4d0/third_party/WebKit/LayoutTests/http/tests/security/contentSecurityPolicy/report-blocked-uri-cross-origin-expected.txt
[modify] https://crrev.com/a98bc6ea35dbcc498eaa7a84b67e91622d8eb4d0/third_party/WebKit/LayoutTests/http/tests/security/contentSecurityPolicy/report-blocked-uri-expected.txt
[modify] https://crrev.com/a98bc6ea35dbcc498eaa7a84b67e91622d8eb4d0/third_party/WebKit/LayoutTests/http/tests/security/contentSecurityPolicy/report-multiple-violations-01-expected.txt
[modify] https://crrev.com/a98bc6ea35dbcc498eaa7a84b67e91622d8eb4d0/third_party/WebKit/LayoutTests/http/tests/security/contentSecurityPolicy/report-original-url.php
[modify] https://crrev.com/a98bc6ea35dbcc498eaa7a84b67e91622d8eb4d0/third_party/WebKit/LayoutTests/http/tests/security/contentSecurityPolicy/report-uri-multiple-expected.txt
[modify] https://crrev.com/a98bc6ea35dbcc498eaa7a84b67e91622d8eb4d0/third_party/WebKit/LayoutTests/http/tests/security/contentSecurityPolicy/report-uri-multiple-reversed-expected.txt
[modify] https://crrev.com/a98bc6ea35dbcc498eaa7a84b67e91622d8eb4d0/third_party/WebKit/Source/core/frame/csp/ContentSecurityPolicy.cpp
[modify] https://crrev.com/a98bc6ea35dbcc498eaa7a84b67e91622d8eb4d0/third_party/WebKit/Source/core/frame/csp/ContentSecurityPolicy.h
[modify] https://crrev.com/a98bc6ea35dbcc498eaa7a84b67e91622d8eb4d0/third_party/WebKit/Source/core/frame/csp/ContentSecurityPolicyTest.cpp
[modify] https://crrev.com/a98bc6ea35dbcc498eaa7a84b67e91622d8eb4d0/third_party/WebKit/Source/core/loader/DocumentLoader.cpp
[modify] https://crrev.com/a98bc6ea35dbcc498eaa7a84b67e91622d8eb4d0/third_party/WebKit/Source/core/loader/FrameFetchContext.cpp
[modify] https://crrev.com/a98bc6ea35dbcc498eaa7a84b67e91622d8eb4d0/third_party/WebKit/Source/core/loader/FrameFetchContext.h
[modify] https://crrev.com/a98bc6ea35dbcc498eaa7a84b67e91622d8eb4d0/third_party/WebKit/Source/core/loader/FrameFetchContextTest.cpp
[modify] https://crrev.com/a98bc6ea35dbcc498eaa7a84b67e91622d8eb4d0/third_party/WebKit/Source/core/loader/FrameLoader.cpp
[modify] https://crrev.com/a98bc6ea35dbcc498eaa7a84b67e91622d8eb4d0/third_party/WebKit/Source/core/loader/FrameLoader.h
[modify] https://crrev.com/a98bc6ea35dbcc498eaa7a84b67e91622d8eb4d0/third_party/WebKit/Source/platform/loader/fetch/FetchContext.cpp
[modify] https://crrev.com/a98bc6ea35dbcc498eaa7a84b67e91622d8eb4d0/third_party/WebKit/Source/platform/loader/fetch/FetchContext.h
[modify] https://crrev.com/a98bc6ea35dbcc498eaa7a84b67e91622d8eb4d0/third_party/WebKit/Source/platform/loader/fetch/ResourceFetcher.cpp
[modify] https://crrev.com/a98bc6ea35dbcc498eaa7a84b67e91622d8eb4d0/third_party/WebKit/Source/platform/loader/fetch/ResourceLoader.cpp
[modify] https://crrev.com/a98bc6ea35dbcc498eaa7a84b67e91622d8eb4d0/third_party/WebKit/Source/platform/loader/testing/MockFetchContext.h

Follow-up bug for PlzNavigate is issue 713388