RESOLVED CONFIGURATION CHANGED Bug 159118
upgrade-insecure-requests does not upgrade HTTP URI's after being redirected 
https://bugs.webkit.org/show_bug.cgi?id=159118
Summary upgrade-insecure-requests does not upgrade HTTP URI's after being redirected
Zack Tollman
Reported 2016-06-25 11:57:45 PDT
Created attachment 282080 [details] Flowchart to describe expected and actual upgrades Steps to reproduce the problem: 1. Generate a page with the following CSP header: `default-src https:; upgrade-insecure-requests` 2. Create a HTML page, protected by the CSP in step 1, that contains an `img` tag with a `src` attribute pointing to an HTTP asset (request A), that can successfully be upgraded to an HTTPS (request B) asset via `upgrade-insecure-requests`. This HTTPS asset should then redirect, via the server, to an HTTP asset (request C). Note that this HTTP asset should work as an HTTP or HTTPS request, but the redirect should specifically be to the HTTP version of the asset. 3. Remove, and possibly flush, any HSTS headers set for the test domain. You can view a test case here: https://test-run-dot-csp-unit.appspot.com/tests/bdfab057-5f90-466f-afdd-0d67ca9c5458. In the test case, http://goo.gl/fDn2aT is upgraded to https://goo.gl/fDn2aT, which redirects to http://placeholdit.imgix.net/~text?txtsize=33&txt=350%C3%97150&w=350&h=150, but *is not* upgraded to https://placeholdit.imgix.net/~text?txtsize=33&txt=350%C3%97150&w=350&h=150 as I would expect. What is the expected behavior? It is expected that request C should be upgraded to an HTTPS request via `upgrade-insecure-requests`. What went wrong? Request C is not upgraded via `upgrade-insecure-requests` and subsequently blocked by the `default-src https:` CSP directive: Refused to load http://placeholdit.imgix.net/~text?txtsize=33&txt=350%C3%97150&w=350&h=150 because it appears in neither the img-src directive nor the default-src directive of the Content Security Policy.
Attachments
Flowchart to describe expected and actual upgrades (36.12 KB, image/png)
2016-06-25 11:57 PDT, Zack Tollman 		no flags
Details
Test (234 bytes, text/html)
2017-11-06 12:07 PST, Daniel Bates 		no flags
Details
View All Add attachment proposed patch, testcase, etc.
Zack Tollman
Comment 1 2016-06-25 11:58:35 PDT
I forgot to note that this is also a bug in Chrome (https://bugs.chromium.org/p/chromium/issues/detail?id=615885), but handled properly in Firefox.
Zack Tollman
Comment 2 2016-06-25 12:11:24 PDT
Looks like I already reported this here: https://bugs.webkit.org/show_bug.cgi?id=158389, but forgot about it. I think this report is better than the previous one and am thus going to close the older one.
Zack Tollman
Comment 3 2016-06-25 12:12:53 PDT
*** Bug 158389 has been marked as a duplicate of this bug. ***
Radar WebKit Bug Importer
Comment 4 2016-06-26 11:27:47 PDT
<rdar://problem/27018807>
Daniel Bates
Comment 5 2017-11-06 12:07:07 PST
Created attachment 326144 [details] Test
Daniel Bates
Comment 6 2017-11-06 12:09:13 PST
@Zack: Are you still able to reproduce this issue? I am unable to reproduce this issue in top-of-tree WebKit using the attached test case (attachment #326144 [details]).
Brent Fulgham
Comment 7 2022-08-08 15:02:15 PDT
This appears to work properly in Safari 15.5 (and newer).
Note You need to log in before you can comment on or make changes to this bug.